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Preface 


This logic manual describes the internal functioning of the Remote 
Spooling Communications Subsystem Networking program product. This 
manual is for IBM program support representatives, and system 
programmers and analysts responsible for installation, maintenance, and 
modification of RSCS. 


| 
| 


| 
Note: | 
In this manual the term "RSCS" refers to the | 
Remote Spooling Communications Subsystem Networking | 
program product. It does not refer to the Remote ! 
Spooling Communications Subsystem component of | 
VM/370. Where these two different programs are | 

| 


discussed together, the difference is made clear. 


fo ce ee me ee 


This manual assists in isolating RSCS module code. It gives: 
e An overview of RSCS operations 


e Descriptions of RSCS's user functions with reference to the tasks and 
modules that perform them 


e A description of each module's main routines and linkages 

e Control flow diagrams of iateu-eoutine inter-task relationships 
® Locations and contents of data areas 

e An approach to problem determination 


e Appendixes with reference material on MUILTI-LFAVING and the RSCS 
Preloader utility under CMS. 


These sections document the program logic sufficiently to point to the 
module listing that the logic manual user needs. Once in a module 
listing, the user should readily find the logic he is concerned with, 
using module and subroutine headers (prologues) and the comments in the 
assembler language statements. 


RSCS runs as a virtual machine under the V#/370 Control Program (CP). 
In extending the VM/370 spooling system capability to include spooling 
to remote stations, RSCS interacts with the CP spooling systen. 
Therefore, some of the information in this publication requires a 
knowledge of that area of CP. 
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RSCS is a software package in the IBM Network Job Interface series of 
products. Network Job Interface (NJI) is a remote spooling capability 
comprising several software packages that provide the support for the 
transmission of files (including jobs and job output data) between 
processors attached to a telecommunications network. The processors 
that are nodes in the network can be running the same or different 
spooling systems, with the common requirement that each runs one of the 
NJI or NJE (Network Job Entry) support packages. 


RSCS is a program product that provides NJI support on those nodes in 
the network that are VM/370 systems. RSCS is a virtual machine 
subsystem, operating independently of other virtual machines running 
under the VM/3/0 control program, CP. USing the RSCS command lanquage, 
the RSCS operator manages his node in the network, and can issue some 
commands to other nodes in the network. 


Within the network, there can also be both CPUs and terminals that 
contain no NJI/NJE support. These do not function as intermediate nodes 
- they have subhost status - and can, depending upon their configura- 
tions, perform operations such as: submit files (jobs); receive files 
(jobs); or both submit files that are jobs and receive their output. 


The processor with an RSCS virtual machine is a relay point, ina 
network, for data: 


e From other virtual machines under its own VM/370 system either to 
remote processors, or to remote batch stations 


e From other nodes to virtual machines on its own processor 
e From other nodes to either other nodes or remote batch stations. 


The data relay facility of RSCS is provided by its "store and forward" 
functions, which use the VM/370 CP spooling facility to temporarily hold 
incoming and outgoing files. 


When the data RSCS is transferring is to be forwarded from node to node 
in the network to the data's ultimate destination, each forwarding node 
must have the store-and-forward and routing capability provided by one 

of the NJI or NJE support packages. 


When the data that RSCS is transferring is a job to be executed 
remotely, and if the job output is to be returned to an interactive user 
or to an indirectly connected system or workstation, the destination 
system must have the job entry capability provided by one of the NJI or 
NJE support packages. 


The output of a routed job executed at a remote non-V¥MN/370 NJI/NJE 
system is routed to the real unit record equipment at the submitter's 
location unless explicitly overridden by the user. The submitter may 
include in his jobstream NJI control statements to route the remotely 
executed job output to another destination or destinations. 


The output of a routed CMS batch job executed at a remote VM/370 system 
can be routed to the job's originator by including appropriate CMS 
commands with the job. 


See the RSCS Program Reference and Operations Manual (listed in the 
Preface) for detailed information about using RSCS. 
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A given RSCS location (or "node") sees only the nodes adjacent to it in 
the network. See Figure 1-1, below. An RSCS "link" is defined at an 
RSCS location as the capacity to communicate with a particular remote 
location via a direct connection. This includes dialup, leased line, 
and channel-to-channel adapter (CTCA) connections. 
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Figure 1-1. RSCS - Sample Network 


RSCS Overview 


Figure 1-2 is an overview of RSCS operations in a simple network. (Wot 
all network nodes must be VM/370 RSCS nodes; this figure shows the types 
of operations that RSCS supports.) Refer to Figure 1-2 when reading the 
following description. 


User Archie on the CMS system at VM1 sends a file to user Bob on the CMS 
System at VM3. Archie issues the commands: 


SP 00D TO RSCS1 
TAG DEV OOD VM3 BOB 
PUNCH filename filetype 


CP spools his virtual punch 00D output to RSCS1. RSCS1 may have any 


number of links to the other network nodes, but it has locally-specified 
tables that indicate that files for VM3 are to go to WM2. RSCS1 
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+ a +h 3 ; 
forwards the spool file, including its desti 


ormat 
RSCS2 on VM2 receives the file, spools it to its own userid 
forwards it to WM3. RSCS3 at VN3 recognizes that the file 
own location and spools it to userid Bob. 


nation inf n, to YM2 


ed ¥isae@ 


io 
, and 
is for its 


These functions are explained in more detail in Section 2. 


VM1 VM2 VM3 


lai “Fl Fr 


@ @ 
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Figure 1-2. RSCS File Handling 


The RSCS Virtual Machine and the VM/370 Control Program (CP) 


Like other VM/370 virtual machines, the RSCS virtual machine runs under 
the‘control of CP. In extending the WM/370 spooling system capability 
to include spooling to resgote stations, RSCS interacts with the CP 
spooling system. Therefore, some of the information in this publication 
requires a knowledge of that area of CP. 


The RSCS virtual machine consists of the virtual machine operator's 
console, an RSCS system disk, and attached telecommunications lines. 
During system initialization, a virtual card reader is defined for the 
RSCS virtual machine, but this reader does not exist in the CP directory 
entry for the RSCS virtual machine. 


Virtual printers, card punches, and readers are defined dynamically by 
the program as they are needed. For example, when a file from a remote 
station is transmitted to RSCS, a virtual punch is defined to accept the 
file. Similarly, virtual readers are defined when RSCS accepts a spool 
file to transmit. RSCS virtual storage also duaps onto a virtual 
printer when abnormal termination of RSCS occurs. 


The minimum virtual storage required to run RSCS is 384K, with typical 
requirements falling in the 512K to 1M range. 
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Remote System Routes and Links 


At a local installation there are a number of transmission paths to 
remote stations. A unique location identifier (locid) is assigned to 
each remote station. 


For each direct transmission path (nonswitched line) or potential direct 
transmission path (switched line) to an adjacent network node, a link 
must be defined at the installation. Each such link is given a name 
(linkid) that must be the same as the location identifier of the remote 
system or station to which the direct transmission path leads. 


Every successive node along the route connecting nodes that are 
destinations for data must have prespecified routing information. The 
routing information at a given node specifies, for each possible 
destination locid, the link that this node is to use to forward the data. 


The links and routes can be defined (a) permanently, in a CMS file on 
the RSCS system disk called RSCS DIRECT; or (b) temporarily, by the RSCS 
operator commands DEFINE and ROUTE. Temporary definitions disappear at 
the next RSCS IPL. 


Links and routes can be temporarily removed with the RSCS operator 
commands DELETE and ROUTF. Any permanently defined links and routes 
removed by operator commands reappear at the next RSCS IPL. 


The alternate path facility of RSCS enables installations to configure 
their routes and links so as to bypass unavailable links. Refer to 
Figure 1-3 when reading the following description. 


Any node (A) may have both a LINK table entry and a ROUTE table entry 
for an adjacent node (B). A file that has a final destination of node 
B, and is being forwarded by node A, will normally be enqueued on the 
node B link, link B. The ROUTE table entry is used when the final 
destination of the file at node A is the adjacent node B, but link B to 
node B is not available. The ROUTE table entry for node B is an 
alternate path that specifies node C via link C. Node A transmits the 
file to node C, bypassing the unavailable link. See the RSCS Program 


tf the direct link from 
A to B goes down, the 
alternate path in the 
route table is used. 


Cc 
cP RSCS 
Link Table: 
Loot 


A] Rscs 
Link Table: 
B—»B 
Routing Table: 


Figure 1-3. Alternate Path Facility 
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Remote stations are configurations of I/0 devices attached to a VM/370 
system by binary synchronous communications (BSC) switched or 
nonswitched lines. RSCS supports both programmable and nonprogrammable 
remote stations. 


PROGRAMMABLE REMOTE STATIONS 


Programmable remote stations, such as the IBM System/3 and System/370, 
are processing systems with attached BSC adapters. These systems must 
be programmed to provide the MOULTI-LEAVING line protocol necessary for 
their devices to function as remote stations. This programming support 
is provided by a remote terminal processor (RTP) program generated 
according to HASP workstation protocoi and tailored to the system's 
hardware configuration. Certain programmable remote stations like the 
System/3 can only be programmed to function as remote terminals. 
Others, like the System/360 and System/370, can function either as 
remote terminals or as host batch systems using RSCS as a remote job 
entry workstation. Both of these types of remote stations are managed 
by the spool MULTI-LEAVING (SML) line driver of RSCS. 


NONPROGRAMMABLE REMOTE STATIONS 


Nonprogrammable remote stations are I/O configurations that cannot be 
programmed, but are designed to provide the line protocol necessary for 
them to function as remote stations. They can receive, read, print, 
punch, and send files. An example of a nonprogrammable remote station 
is a 3780 Data Transmission Terminal. Nonprogrammable remote stations 
are managed by the NPT (Nonprogrammable Terminal) RSCS line driver. 


REMOTE STATIONS SUPPORTED BY RSCS 


The types of devices supported for all types of remote stations, 
programmable and nonprogrammable, are listed in the RSCS Program 
Reference and Operations Manual. 


REMOTE SYSTEMS SUPPORTED BY RSCS 


The programmable remote systems that RSCS can communicate with are: 


Other RSCS systems 

VNET PRPQ systems 

HASP Networking PRPQ systems 

ASP Networking PRPQ systems 

Network Job Entry Facility for JES2 
JES3 Component of OS/VS2 

RES Component of OS/VS1 

VSE/POWER systems 
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Network Control: RSCS and VM/370 Commands 


Both RSCS and VM/370 commands are used to control RSCS. RSCS commands 
are used by an RSCS operator to control the network; V¥M/370 CP and CMS 
commands are used by virtual machine users who use RSCS. 


RSCS OPERATOR COMMANDS 


To manipulate the file being transmitted across the network and to 
communicate with the various network users, RSCS provides a command 
language. Figure 1-4 lists the RSCS commands and the functions they 
perform. Detailed descriptions of these commands are in the RSCS 
Reference and Operations Manual. 


The operator may enter RSCS commands described in Figure 1-4 at the RSCS 
virtual machine console. A subset of the RSCS command language may be 
entered by operators of remote stations or remote systems. 


VM/370 CP AND CMS COMMANDS FOR RSCS 


The VM/370 CP TAG and SPOOL commands specify a device to be spooled, and 
they associate a destination location identifier (locid) with that 
device. SPOOL directs the file to the RSCS virtual machine. The CP 
CLOSE command or the CMS PRINT or PUNCH commands close the file and 
transfer it to the RSCS virtual machine. 


Data specified by the CP TAG command controls processing of files 
transmitted across the network. When a V4/370 user creates, on his 
virtual machine, a file to be transmitted to a remote station via RSCS, 
the CP TAG command must contain information needed by RSCS. 


A virtual machine user may use the CP SMSG (Special Message) command to 
send messages via RSCS to remote virtual machines or to request status 
information about a local or remote RSCS or about a remote V8/370 
system. The text of an SHSG command can be an RSCS MSG command or an 
RSCS CMD command; the text of that CMD command can be an RSCS QUERY 
command or an RSCS CPQUERY command. 


For details on how to use the CP SPOOL, TAG, and SMSG commands, see the 
RSCS Reference and Operations Manual. 
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Command | 


communication link. 
Th cdc cans elt een ic icici pip md cel eae ema te ccc cating eee et isis catia 


{ Name H Function ! 
t 

| * { Comment following asterisk prints out on RSCS | 
| | operator console, and no function is performed. | 
I | (Useful for CMS EXEC files of RSCS commands, 1 
| | particularly the PROFILE RSCS file.) | 
| | | 
| BACKSPAC | Restarts or repositions in a backward direction | 
{ | the file currently being transmitted. { 
j i 1 
{ CHANGE | Alters one or more attributes of a file owned by | 
\ { 1 
| CLOSE | Deactivates partially processed files on an { 
{ | inactive link. Discards output (incoming) files. | 
t | Reengueues active input files as inactive files. t 
I I i 
{| CMD { Forwards a command line to a remote system for | 
| | execution. | 
| ! I 
{| CP | Executes a command line as a VM/370 Control | 
| | Program (CP) console function. | 
| | | 
{ CPQUERY | Requests status information from CP, similar 1 
! | to a VM/370 CP QUERY command { 
I { | 
| DEFINE | Temporarily adds a new Link definition to the | 
| { RSCS link table, or temporarily alters an | 
| | existing link definition. | 
I | | 
| DELETE | Temporarily deletes a link definition from the ! 
{ { RSCS link table. | 
I | { 
| DISCONN | Places RSCS in disconnect mode and optionally | 
| | directs RSCS operator console output to another | 
| {| virtual machine. | 
| | | 
{ DRAIN | Quiesces file transfer and deactivates an active | 
{ | | 


Figure 1-4. RSCS Commands and Their Functions (Part 1 of 2) 
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Se ee Se 
| Command | I 


| Name | Function 1 
| EXEC | Executes series of RSCS commands contained in the | 
| | specified user-built CMS file (filetype: RSCS). | 
t | | 
| FLUSH | Discontinues processing the currently active file | 
\ {| on the specified link. 1 
{ | ! 
] FORCE | Immediately deactivates an active link, without | 
{ 1 quiescing file transfer. { 
j l | 
| FREE j Resumes transmission on a communication link | 
J { previously in HOLD status. | 
{ ! | 
| FWDSPACE | Repositions in a forward direction the file | 
| | currently being transmitted. I 
| { | 
{| HOLD | Suspends file transmission on an active link | 
{ { without deactivating the link. | 
I | ; | 
| HI | Flushes out all messages presently awaiting { 
{ | printing on the RSCS operator console or | 
H { remote station operator console. | 
| | 1 
{ MSG | Sends a console message line to a local or { 
{ | remote operator or user. | 
| { | 
| ORDER | Reorders files enqueued on a specific link. | 
| { { 
{ PURGE {| Removes and discards all or specified inactive | 
| { files from a Link. | 
| | I 
| QUERY {| Requests system information for a link, a file, { 
| { or for the system in general. | 
{ | | 
| REORDER { Sorts and reorders all files enqueued for all | 
{ {| links. | 
{ | i 
| ROUTE | Adds, deletes, or alters an RSCS routing table ! 
| | entry. i 
| { { 
{| START | Activates a specified communication link. | 
I t | 
{| SHUTDOWN | Issues DRAIN to all active links. | 
! | | 
{ TRACE | Monitors line activity on a specified link. | 
| | { 
| TRANSFER | Changes the destination address for specified | 
| { | 


files. 


Figure 1-4. RSCS Commands and Their Functions (Part 2 of 2) 


CP INSTRUCTIONS USED BY THE RSCS CONTROL PROGRAM: DIAGNOSE 


When RSCS handles files being transmitted across the network, the RSCS 
control program and line driver tasks issue DIAGNOSE instructions to 
obtain CP services. 
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A DIAGNOSE instruction is used in YM/370 for communication hetween a 
virtual machine and CP. The machine-coded format for the VM/370 usage 
of the DIAGNOSE instruction is: 

0 7 8 1112 15 16 31 

Oo a Pe ee een ee ae oe ae ee a 

| 83 { Rx | Ry f{ Code | 

| se SN Se | 

Content Explanation 

83 DIAGNOSF operation code 

RX User-specified register number 

Ry User-specified register number 

Code Hexadecimal value that selects a particular CP function. 


Figure 1-5 lists the DIAGNOSE function codes used by RSCS, the functions 
of those codes, and the RSCS modules from which they are issued. 


RSCS Preparation and Startup 


RSCS PREPARATION 


The preparations for running RSCS on a VM/370 system are explained in 
VH/370: RSCS Networking Program Reference and Operations. In summary, 
the preparations are: 


e Load RSCS modules onto disk. 
e If required, perform updates to modules. 


e If required, use the Preloader utility (see Appendix 8B) to combine and 
link multiple nodules. 


e Use the CMS editor to build the directory file (RSCS DIRECT) to 
specify parameters for the RSCS virtual system. These specifications 
include installation variables and link and route definitions 
describing communication paths to remote locations. 


e If desired, use the CMS editor to build the PROFILF RSCS file to 
specify installation STARTUP commands. 


DYNAMIC DIRECTORY 


There is no system generation (requiring assembly) for RSCS. 


Each time RSCS is IPLed it dynamically configures itself, referring to 
the contents of a file (named RSCS DIRECT) on the RSCS system disk. The 
local system programmer builds and updates this file. This file 
specifies the RSCS configuration and characteristics desired for this 
location. The file can be updated to incorporate new link specifi- 
cations, new routing table entries, etc. as desired even during RSCS 
operation; the changes become effective on the next RSCS IPL. 


During operation, the RSCS operator can enter commands that immediately 


modify some of the RSCS DIRECT-specified characteristics. But these 
commands (such as ROUTE, LINK, DEFINE, and DELETE) are in effect only 
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temporarily; when RSCS is re-IPLed, only the RSCS DIFECT statements 
remain in effect. 


The details of the contents of RSCS DIRECT are in the RSCS Progra 


fo ee tN en ee eS ee re ee Re eee et ee a A eg) ee ea Se 
| DIAGNOSE Code | Function [Issued by Module(s) | 

———__——__—$______—_‘__ 
| 0000 | Gets the userid of the RSCS { DMTIRX | 
| { virtual machine. | | 
| ! | i 
| 0008 { Executes a CP command. Results | DMTAX I 
| | may be returned in a buffer or | DMTCMX | 
| { sent to the virtual console. | DM TMGX | 
| | | DAMTREX { 
| | | I 
| 000c {| Gets the current time and date. | DMTAXA { 
| | | DMTNCM j 
| 1 | DATNPT { 
| | | DMTSML ] 
| { DMTVMB | 
| | | DATVHC j 
i I { DMTPOW | 
1 { ! | 
| 0010 | Frees virtual storage page. { DMTASK | 
| ] | DMTCOM ] 
| | { | 
| 0014 | Manipulates input spool files. | DMTAXM { 
{ | { DMATNCH# | 
| | {| DMTNPT | 
| | | DM TSNL 1 
| I | DMTVMB ] 
| | | DM TVMC | 
{ i | DMT POW | 
| { | | 
| 0020 | Performs DASD I/O without { DMTINI { 
| { interrupt. { | 
I | ! { 
| 0024 | Determines virtual device type |] DMTIRX | 
| | information. | DMTLAX { 
j | | DMTNCM | 
| { | DMTREX ] 
{ | { DMTSML | 
l | | DMT POW I 
| | { { 
| 004Cc {| Generate an RSCS accounting | DMTAXA | 
{ | record. { { 
| | | { 
| 005C {| Edits RSCS messages. 1 DMTMGX { 
| | | | 
I 0068 | CP vehicle for sending Special { DMTIRX 1 
| I | 


Messages to RSCS. {| DMTREX 


nn ce ee en ee ener ee researc eeeeecnneerenemenenll 


Figure 1-5. VM/370 DIAGNOSE Instructions Issued by RSCS 
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Section 2: Method of Operation 


The RSCS Control Program 


RSCS is a virtual machine subsystem, with a multitasking supervisor 
(MSUP) that manages multiple independent programs called tasks. 


The MSUP supervisor is the heart of the RSCS virtual machine. It is a 
set of routines and storage areas that coordinate the operation of RSCS. 


The tasks are modules or sets of modules that perforr RSCS functions. 
The task modules are executed under control of the MSUP supervisor. 


The supervisor provides only those functions that cannot be consistently 
provided by the tasks themselves; that is, the supervisor provides only 
the support needed to control and coordinate the execution of the tasks. 


The two types of RSCS tasks are system service tasks and line driver 
tasks. System service tasks provide the system support functions for 
the supervisor and for other tasks. Line driver tasks manage the 
transmission paths to remote systems and stations, and interact between 
the remote stations and the system service tasks and the supervisor. 
Fach line driver task manages transmission to and from one remote 
station. 


The figures in Section 3 show the communication paths between the MSUP 


supervisor, system service tasks, line driver tasks, remote stations, 
and VM/370 virtual machines. 


MSUP: THE RSCS SUPERVISOP 


The MSUP supervisor is a set of service routines that provide functions 
for the tasks that run under them These service routines may be called 
by any task. In general, they provide four kinds of services: 

e Task management 

e I/O management 


e Interrupt handling 


e Virtual storage management 


TASK MANAGEMENT 


The task management service routines provide task initiation and 
termination, task dispatching, task-to-task communication, and task 
synchronization. 


Task initiation consists of making a task that has been loaded into 
virtual storage available for execution. This inciudes: 


(a) Building a TASKE entry for the task in the task queue pointed 
to by the SVECTORS field, TASKQ (X'228'); and 
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(b) Marking the task dispatchable so that its initialization 
routine is entered. 


In general, the only task to request task initiation and termination is 
the REX system control task, which is described below. 


Task dispatching consists of scanning the task queue entries (TASKE) for 
tasks that are able to continue executing, and allowing them to execute 
one at a time. 


The two types of task-to-task communications are (1) the DMTSIG routine 
(ALERT) and (2) the DMTGIV and DMTAKE routines (GIVE/TAKE). 


The DMTSIG routine allows a task to immediately invoke another task to 
pass it information. The interrupted task must have an asynchronous 
exit routine defined to handle the interruption. Functionally, DMTSIG 
performs a function analogous to an SVC instruction. 


The DMTGIV and DMTAKE routines allow tasks to exchange information 
buffers with other tasks. The GIVE/TAKE function provides organized 
engueuing and delivery of requests for services or information from one 
task to another. This function is roughly analogous to write-read 1/0 
operation. 


Task synchronization involves making tasks ready or not ready for 
execution under control of the dispatcher. When a task requests the 
services of another task, the requesting task may suspend its execution 
while the request is being processed. The synchronization mechanisn 
consists of two routines, DMTWAT and DMTPST. DMTWAT causes the 
requesting task to temporarily halt execution. DMTPST causes a 
temporarily-halted task to resume execution. For more information on 
task synchronization refer to the section "Task Synchronization". 


A task that requests supervisor service by branching to a supervisor 
routine is placed in non-executing mode with a FREEZE SVC, which is 
issued by the called supervisor routine. 


atching in RSCS 


o 
wi 
nn 


The supervisor returns control to the tasks by means of the dispatcher 
(DMNTDSP). The dispatcher scans the queue of tasks to be executed (TASKE 
in SVECTORS), selects the first dispatchable task element (that is, one 
that is not marked nondispatchable by DMTWAT), moves this task element 
to the end of the task queue, and restarts its execution. If no task 
element is dispatchable, a masked-on wait state PSW is loaded by the 
dispatcher. 


To suspend its execution, the requesting task calls DMTWAT, which 
inspects the synchronization locks FPSCS uses to synchronize task 
execution. Completion of a service is signalled by means of a synch 
lock, which is set (or "posted") by DMTPST. 


3 


ask-to-Task Communications 








Sometimes a task requires the services of another task to complete a 
function. For example, VMB may require that AXM open a file for input 
before VMB processing can continue. RSCS tasks communicate with each 
other to request these kinds of services using two methods: ALERT 
task-to-task communication, and GIVE/TAKE communication. 
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h methods use an element, which is a table of information that 


nt 
escribes the nature of the request. In general, these elements are 
alled “request elements" and "alert elements". 


Q m& to 


The ALERT mechanism is an asynchronous interrupt that causes the 
requested task to examine the request immediately and uninterruptably. 
When the requested task processing is complete, control is passed to the 
MSUP dispatcher. The requestor task remains dispatchable. 


The GIVE/TAKE mechanism allows the requested task to service the request 
in the course of normal task dispatching. The requesting task remains 
dispatchable unless it requests a WAIT on the GIVE synch lock. 


RSCS has a three-level task hierarchy implemented in task programming, 
but not checked or controlled by the MSUP supervisor. The hierarchy is: 
(a) the REX task is highest, (b) the AXS and LAX tasks are next, and (c) 
the line driver tasks are lowest. 


This hierarchy is foliowed in task-to-task communications. A task 
issues an ALERT to only a lower task. A task issues a GIVE to only a 
higher task. A task never communicates directly with a task equal to it 
in the hierarchy. 


The GIVE/TAKE method provides ordered enqueuing of requests for 
services. Such a request is handled when the servicing task is free to 
handle it, rather than upon immediate demand. Figure 2-1 and the 
following descriptions explain the GIVE/TAKE task-to-task communication 
process. 


REQUEST AND RESPONSE ELEMENTS: Generally, request and response elements 
are tables of information that reside in the storage of both the 
requesting task and the task providing the service. During task-to-task 
communication, these elements are passed from one task to another, 
containing either requests for services or responses to requests. 


GIVE/TAKE, it builds a GIVE table, a GIVE request buffer, and a GIVE 
response buffer in its storage. (The request and response buffers may 
be at the same location in storage,) 


The GIVE request buffer contains a GIVE request element (a table of 
information describing the service requested). After the GIVE request 
element is built, the requesting task clears the synch lock in its GIVE 
table to zero (in preparation for a call to DMTWAT) and specifies the 
address of the GIVE table in a call to DMTGIV. 


SUPERVISOR HANDLING OF GIVE REQUESTS: The supervisor routine DMTGIV then 
builds and enqueues a supervisor GIVE element containing a pointer to 
the GIVE table, so that the request can be forwarded to the receiving 
task when that task is ready to accept the request. 


TAKING A GLVE REQUEST: When the receiving task is ready to process a 
GIVE request, the receiving task prepares a TAKE table in its own 
storage. The TAKE table consists of a field to receive the task name of 
the requesting task and the addresses and the lengths of a TAKE request 
buffer and a TAKE response buffer. Functionally, these buffers 
complement the GIVE request and response buffers and, like the GIVE 
buffers, may be at the same location in storage. 
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Figure 2-1. Movement of Data During a Typical GIVE/TAKE Transaction 


After the TAKE table is built, the receiving task specifies the address 
of the TAKE table in a call to DMTAKE. The supervisor then moves the 
GIVE request buffer (containing the GIVE request element) to the 
receiving task's TAKE request buffer. 


RFSPONDING TO A GIVE REQUEST: The receiving task performs the requested 
service, and may update the GIVE request element and place it in its 
TAKE response buffer. This modified GIVE request element contains 
information on results of request processing to hbe returned to the 
requesting task. 


When all requested processing is complete, the receiving task again 
calls DMTAKE, specifying the address of the TAKE table. The supervisor 
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responds by immediately moving the contents of the receiving task's TAKE 
reponse buffer to the requesting task's GIVE response buffer, and 
posting the synch lock in the requesting task's GIVE table. 


addressed to the receiving task has been enqueued, it is given to the 
receiving task as described above, and dispatched task execution is 
resumed. On each call to it, DMNTAKE first responds to a previously 
accepted GIVE request (if one exists) and then gives another modified 
GIVE request element back to the requesting task (if one exists). 


WAITING FOR REQUEST COMPLETION: The requesting task waits for request 
completion by specifying the address of the synch lock in its GIVE table 
in a call to the WAIT routine (DMTWAT). 


The receiving task waits for request availability by calling DMTWAT and 
specifying the address of its take request synch lock, which is located 
in its Task Save Area. The take request synch lock is cleared to zero 
by DMTAKE when no GIVE request address to the calling task remains 
enqueued. It is posted by DMTGIV when such a request is enqueued as a 
result of DMTGIV processing for another task. 


Synchronization locks (or synch locks) are fullwords in task save areas 
or control tables (such as TAREA or IOTABLE). Synch locks are also in 
control areas in function selector routines. 


A synch lock is a location in storage where a task that requests a 
service from another task receives notice of the completion of that 
service. Task code may contain any number of synch locks, depending on 
the number and types of service it needs. 


The addressability of each synch lock for posting upon completion of the 
requested service depends upon the type of request. For example, the 


mr 2m ee ee oe; 4 #5 . : . 
GIVE/TAKE reguest synch lock is a fixed location. It is in the Task 


Save Area, TAREA, at x*48* bytes from the start of the task. The 1/0 
synch lock, however, is at the first of the requesting task's I/0 table, 
whose address is passed with the requesting task's BALR to the I/0 
request handler (see “Handling I/0 Requests"). 


The synch lock must be set to zero before the request for services is 
made. Setting the synch lock to zero prepares it for processing by the 
request servicer and the WAIT routine. 


The requesting task (the caller of DMTWAT) may specify the address of a 
single synch lock (as in the case of a GIVE Table or an IOTABLE), or the 
address of a list of synch locks, one of which must be posted by DMSTPST 
before dispatching of the requesting task can resume. Figure 2-2 shows 
the contents of Register 1 on a call to DMTWAT. 
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Figure 2-2. Input to the DMTWAT Routine 


Posting a Synch Lock 


When the requested service is complete, the receiving task signals 
completion by calling the POST routine (DMTPST), specifying the 
requesting task‘'s associated synch lock. The POST routine sets the 
high-order byte of the synch lock to nonzero. This is referred to as 
"posting" that synch lock, and indicates that the requested service is 
complete. 


If the low-order bytes of the synch lock contain an address indicating 
that the task issued a WAIT on this synch lock, the POST routine also 
marks the requesting task dispatchable in its request element TASKE in 
the TASKQ, and sets the last three bytes of the synch lock to zero. 


Waiting For GIVE/TAKE Fequested Services: DMIWAT 


Before a task can use the results of requested service, it must ensure 
that the service has been performed. The requesting task signals that 
it is waiting for completion of a service via a call to the supervisor 
routine DMTWAT, specifying the synch lock associated with the requested 
service. 


If the high-order byte of the task's synch lock is nonzero when DMTWAT 
inspects it, control is returned directly to the requesting task. If 
the high-order byte of the synch lock is zero, DMTWAT marks the request- 
ing task nondispatchable (in the task's request element, TASKE), stores 
the address of the task's request element in the low-order bytes of the 
synch lock, and resumes dispatching for other tasks. 


Tasks may call DMTWAT specifying multiple synch locks. This is an "OR" 
condition; the task wants to run if any of the specified synch locks 
gets posted. Upon such a call, each synch lock is inspected and, if any 
synch lock is posted, task execution resumes immediately (the wait is 
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Satisfied). If none of the synch Locks is posted, the task 


the calling task is marked nondispatchable, its address is stored in 
each synch lock, and dispatching is resumed for other tasks. 


lement for 


When any synch lock in the list is posted, the task element is marked 
dispatchable. The dispatcher clears the low-order three bytes of each 
of the task's synch locks before task execution is resumed. 


Asynchronous Interruptions and £ 


Asynchronous interruptions are unpredictable and must be handled as they 
occur. The three kinds of asynchronous interrupts are I/0, alert, and 
external. 


Any RSCS task that has code (called an asynchronous exit routine) to 
process asynchronous interrupts of a given type notifies the supervisor, 
usually during task initialization, by a branch to the supervisor DMTASY 
module. This reutine builds an entry in the appropriate asynchronous 
interrupt queue that is scanned for "takers" whenever an asynchronous 
exit condition arises. 


Asynchronous exits are provided for external interruptions, for certain 
I/O interruptions, and for ALERT requests that occur during execution of 
another task. 


Asynchronous exit routines in RSCS tasks perform limited function, often 
enqueuing requests for further processing at a later time by dispatched 
tasks. When the asynchronous exit routine completes processing, it 
returns control to the supervisor, which then resumes dispatching tasks 
via a call to the dispatcher (DMTDSP). 





The ALERT method of task-to-task communication allows a task to 
immediately invoke a service in another task, bypassing the normal task 
selection mechanism. 


Initially, a task that services alert requests issues an asynchronous 
exit request for alerts. The request specifies the adiress of its 
routine, called an asynchronous exit, that will process alerts to this 
task. The asynchronous request processor (supervisor module DMTASY) 
takes control, and records this information in an alert asynchronous 
exit queue element. The requesting task is made dispatchable to enable 
it to continue processing beyond its asynchronous exit request. 


When a task requires a certain task's alert service, it issues an alert 
request by branching to DMTSIG, specifying the task to be alerted, and 
the address of its own alert element, if any, which specifies a request 
for processing by the alerted task. 


The type of request is described in the ALERT element. The contents of 

the alert element depend on the type(s) of alert request defined by the 

alerted task. See Section 5 for alert element formats. 

The supervisor responds by giving control to the alert asynchronous exit 
routine of the specified task and by passing to that task the address of 
the requesting task's ALERT element. 


The asynchronous exit routine responds immediately and may copy the 
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ALERT element into its own storage for further processing. The 
asynchronous exit routine then returns control to the supervisor, which 
allows the dispatched task to resume execution. The following 
summarizes the terms used in the ALERT capability: 


The task that will handle ALERT requests via its asynchronous exit 
initiates this process with an asynchronous interrupt request. 


The request for the services of another task's ALERT exit routine 
is called an ALERT request. 


RSCS TASK DESCRIPTIONS 


As described previously, the MSUP supervisor is a set of routines that 
Manage RSCS processing. The supervisor is a nucleus that supports the 
RSCS tasks. (These tasks are analogous to virtual machines under ¥M/370 
CP, and tasks under OS/VS systems.) 


The RSCS system service tasks perform less generalized common functions 
for the system than those functions performed by MSUP. For example, the 
AXS system service task coordinates common task access to the V§M/370 

spool file system. Each line driver task manages the communication with 
the single remote system or station that its link is defined to provide. 


The supervisor gives equal priority to all RSCS tasks, and. makes no 
distinction between system service tasks and line driver tasks. Figure 
2-3 lists the RSCS tasks and the service each performs. 


ie] 


EX Task Module Functions 





CREATE SYSTEM TASKS: DMTCRE The main system service task, REX, is loaded 
with the supervisor during RSCS initialization. The REX task, in turn, 
creates other tasks required by the system. DMTCRE reads these other 
tasks from a CMS disk by means of a CMS read access method, located in 
DMTCOM. The task is then started as a new active task under RSCS. 


PROCESS COMMANDS: DMTCMX DMTCMX receives commands by either GIVE request 


elements passed by line driver tasks, or from console-entered commands 
(via DMTREX). 
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{ Task { Module | | 
{| Name {| Name jf Function | 
DMTREX Handles RSCS operator console I/0; accepts 
requests for services passed by other systen 
service tasks or line driver tasks; terminates a 
task; handles program check interruptions. 


DMTCRE Loads and creates a system service or line driver 
task. 
DMTCMX Interprets RSCS command lines, and either executes 


{ 
[ 
I 
| 
1 
! 
| 
| the commands or forwards command request elements 
| to line drivers for further processing or 

| transmittal. 

{ 

l 

1 

I 

i 

l 

I 


ee ee ee ee ee Le le) 


DMT MGX Builds a message line, and distributes the 
constructed message for delivery or forwarding to 
the appropriate recipient (s). 
DMTRGX Handles command and message routing request 
elements. 
DMTCOM Comprises a number of independent re-entrant 
subroutines which may be called by any task. 
eel 
j| AXs | DMTAXM {| Provides the interface to the VM/370 spool systen. | 


| {| DMTAXA | Provides accounting interface. | 


Sa a | 
| LAX | DMTLAX | Manages communication port allocation. | 


|} 4 


| Line DMTSAL Manages a telecommunications port for a 
{| Driver programmable remote station using RTAM. 
DMTPOW Manages a telecommunications port for a 
VSE/ POWER systen. 
DMTNPT Manages a telecommunications port for a 
nonprogrammable remote station terminal. 
DMTVMB Manages a BSC telecommunications port for a 


| I 
I { 
| | 
( { 
i I 
1 I 
{ | 
| | VWE/370 to WM/370 link. 

| DMTVMC | Manages a channel-to-channel V¥M/370 to VM/370 

| | link. 

| | Comprises the following three modules; manages a 
i j BSC telecommunications port for a WH/376 to 

l | OS/VS NIJI/NJE link. 

I { Manages the communications adapter for communica- 
| { tion with an NJI/NJE subsystem via RSC or CTCA. 

| DMTNHD | Processes network header records. 

{ { 


DMTNIT Performs DMTNJI initialization. 
| Se eee OR TnaaRL) [CSmmR Renew eet (WR Dare a EEE ee eC a a a a ee a ee! | 


DMTNJT 


DMTNCM 


Figure 2-3. RSCS Tasks 


The commands *, DEFINE, DELETE, DISCONN, HT, EXEC, ROUTE, CP, CPQUERY, 
FORCE, QUERY, SHUTDOWN, and START (for inactive links) are executed by 
DMTCMX. Executing these commands generally involves referencing and 
modifying system status tables (SVECTORS, TTAGQ, TLINKS, etc.). 


If the command is not one that DMTCMX executes within its own code, 
DMTCMX examines the command line for syntax errors and then passes it to 
the appropriate task for execution. To do this, DMTCMX generates a 
formatted table called a command alert element to be passed to another 
active task for execution via an ALERT asynchronous exit. 


The commands CHANGE, CLOSE, ORDER, TRANSFER, REORDER, and PURGE are 
executed by DMTAXS; the commands BACKSPAC, CMD, DRAIN, FLUSH, FREE, 
FWDSPACE, HOLD, MSG, TRACE, and START (for active links) are executed by 
the line driver task for the specified link. 
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PROCESS MESSAGES: DMTMGX DMTMGX manages distribution of all RSCS 
messages, which may be generated by REX or by any other RSCS task. Each 
message to be issued is presented to DMTMGX (via GIVE/TAKE for tasks 
other than REX) along with an internal routing code and an internal 
severity code. 


Messages may be addressed to the local RS€S operator console, to the 
local VM/370 operator, to a local VM/370 user console, to a remote 
station operator, or to any combination of these destinations, by the 
routing code. The severity code is defined for each message, and is an 
indication of the importance of the message. 


Messages for the RSCS local operator console are enqueuved for output on 
the RSCS virtual machine console. Messages for the local VM/370 system 
operator and for local virtual machine consoles are issued by executing 
a VM/370 CP MSG command (through the DIAGNOSE 8 interface). Messages 
for remote RSCS operators are presented to the line drivers for the 
associated links by the RSCS MSG alert element interface. 


TERMINATE SYSTEM TASKS AND HANDLE PROGRAM CHECKS: DMNTREX When a line 
driver task requests termination, a TAKE request is passed to DMTREX 
specifying that function. DMTREX marks the task as terminated, then 
searches for active I/O associated with the task. If active I/O is 
found, it is terminated. To ensure that system integrity is maintained 
during the termination of the I/0, a mechanism (at label QUIESE) handles 
situations in which an HIO (Halt I/O instruction) does not take effect 
immediately. 


All RSCS program checks are handled by DMTREX. Program check diagnostic 
information is dumped, a message to the operator is issued, and the RSCS 
system status is modified, depending on the nature of the program check. 
If the program check occurs in a line driver, the line driver execution 
is terminated and its link is deactivated. Otherwise, RSCS 
automatically shuts down. 


ROUTING OF COMMANDS AND MESSAGES: DMTRGX DMTRGX processes command 
routing request elements and message routing request elements. Routing 
request elements received from remote systems are passed to DMTRGX by 
the receiving line driver. If the routing request element is addressed 
to the local location, commands are passed to DMTCMX for processing and 
messages are passed to DMTMGX for distribution to recipients. 


Common Supervisor Routines: DMTCOM 


DMTCOM contains various routines used by RSCS tasks and other supervisor 
routines. The address of a vector table, which points to the individual 
DMTCOM routines, is located at address X'0280' in storage. These 
routines and their functions are descibed in Figure 2-4. 


Communicate with the ¥M/370 Spool File System: DMTAXS 





DMTAXS is RSCS's interface to the VM/370 spool system. When a spool 
file arrives at the RSCS virtual machine, AXS receives the associated 
asynchronous interrupt, reads and interprets the file's VM/370 spool 
file block (SFBLOK) and TAG, enqueues the file for transmission as 
appropriate, and notifies the appropriate line driver of the new file's 
availability. AXS provides a GIVE/TAKE request interface to line driver 
tasks for spool file data input and output, and defines and detaches 
virtual spool I/O devices as needed. Also, AXS provides an interface to 
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! 1 Vector Table { { 
{ Routine Name | Pointer Name | Function 

{ GET LINK I GLINKREQ | Get Link Table entry | 
I | l | 
| GETROUTE 1 GROUTREQ | Get Routing Table entry | 
| | | | 
| GETPAGE { GPAGEREQ | Get page of virtual storage | 
| | { | 
{ FREEPAGE | FPAGEREQ | Free page of virtual storage { 
i { { ! 
| MFI { PM SGREQ | Place entry in message stack | 
| I t i 
| MFO | GMSGREQ | Remove entry from message stack | 
| { { { 
| TODEBCD | GTO DEBCD | Convert S/379 TOD clock to EBCDIC | 
{ { | | 
i TODS370 i GTODS376 { Convert EBCDIC clock value tc S$/3790 H 
{ | |! form | 
I | | | 
{ RCMSOPEN { CMSOPEN | Open a CMS file for input | 
| ! I \ 
{ RCMSGET { CMSGET | Read next record of CMS file 1 
| I l { 
l GETSUPAG | GPAGESUP | Allocate page of virtual storage for | 
| I | | 


supervisor use 
a eee eee 


Figure 2-4. DMTCOM Routines 


DMTCMX for second-level command execution support. 

AXS maintains a queue of a fixed number of virtual storage elements 
(called tag slots) that describe files currently owned by the RSCS 
virtual machine. To maintain RSCS integrity in a simple way when a very 
large number of files is enqueued on the RSCS virtual machine, the 
virtual storage tag queue is not extended during execution. 


When a new file arrives at the RSCS virtual machine, its destination 
locid is examined, and it is accepted only if there is a matching link 
or route linkid for which there is a free tag slot available. If the 
file's destination locid is not defined as a linkid, or as an indirect 
path through the routing table, the file is returned to the user and the 
originating user is notified of the action. If there is no free tag 
slot available for a defined linkid, the file is left "pending", and is 
accepted when a tag slot becomes free. While a file is pending, it is 
not recognized by the RSCS command processors, and cannot be referenced 
through RSCS functions. 


To prevent links from being totally locked out by an exhausted (and 
stagnant) virtual storage tag queue, a minimum number of tag slots is 
reserved for each link. This guarantees that a minimum number of files 
are accepted for each associated link. The number of reserved slots is 
defined during system generation or in the DFFINE command for each link 
to be defined in RSCS. The appropriate number of slots to be reserved 
for each link depends on the expected file traffic, the link's line 
speed, the time the link is to be active, and the desired level of 
service to be provided to the link. This number for each link may be 
arrived at through actual operational experience in each location. 
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Manage Telecommunication Line Allocation: DMTLA 





DMTLAX is responsible for line port resource allocation to line driver 
tasks. DMTLAX allocates available switched ports (when a link is 
activated without a specified line address) through an ALERT request 
interface. When a line port is specifically requested (by virtual 
address), DMTLAX checks the device for validity as a line port. 


Line Driver Tasks: DMNTNPT, DMTSML, DMTVMB, DMTVMC, DMTNJI, 


a ————— — 


oO 


MT POW 








As part of the link activation process, REX (module DMTCRE) loads, for 
each defined link, a line driver module and starts a line driver task to 
service a port to an adjacent node in the network. 


Note that when RSCS is servicing more than one link with the same line 
driver specified, there is a separate copy of the same line driver 
module loaded for the different line driver tasks for each port. 





The general functions of line driver tasks are: 
e Manage I/O on the BSC telecommunications adapter or CTCA. 


e Manage transmission of spool file data via GIVE/TAKE requests to the 
AXS task. 


e Fxecute or forward command alert elements received from the REX task. 


The precise functional requirements for communications management vary 
from line driver to line driver, depending on the type of remote station 
the line driver supports. 


Each line driver maintairs its link status and line activity (TRACE) 
records in the RSCS system status tables. 


Six line drivers are provided. DMTNPT supports remote 2770, 2780, 3770 
(in 2770 mode), and 3780 terminals. DMTSSL supports an RTAM interface 
to remote HASP-type and ASP-type systems or workstations. DMTPOW 
supports communication with VSE/POWER. DMTVMB is for VM/370-to-VMN/370 
communications on BSC lines. DMTVMC is for VM/370-to-VM/370 
communications on channel-to-channel adapters. DMTNJI is for 
communications from VM/370 to an NJI/NJE subsystem on BSC lines or 
channel-to-channel adapters. 


I/O MANAGEMENT 


The two kinds of RSCS I/O operations are: I/0 to spool files and I/0 to 
RSCS virtual devices. For I/O to input spool files, the AXS task and 
line driver tasks use CP DIAGNOSE commands. The procedures for I/0 to 
RSCS system devices, telecommunication adapters, and output spool 
devices are described in this section. 

I/O management for tasks consists of the following functions: 

e Queuing requested I/0 operations 

e Starting I/O operations 


e Handling I/0 interrupts 
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e Terminating completed 1/0 requests. 


Handling 1/0 Requests 


When a task requires an I/O operation, it builds an I/0 request table in 
its own storage and passes the table's address to the I/O manager. This 
table contains the following information: 


A synchronization lock, where I/0 completion is to be posted 

* The address of the device on which the I/O operation is to take place 
e The number of sense bytes to be returned, when applicable 

e The address of the channel program to be executed. 

See Section 5 for the format of the I/O request table. 

The task obtains the If request entry address from its SVECTORS table 
and performs a BALR to it, passing the address of the I/0 table in 
register 1. 

The BALR is to subroutine DMTIOMRQ in module DMTIOM in the REX task. 


Here, the calling task execution is suspended with a FREEZE SVC and the 
request is queued, as described in Figure 2-5. 


ACTIVE ACTIVE ACTIVE 
SVECTORS 10 ENTRY 10 ENTRY 10 ENTRY 


MPXIOQ 
IOEXITQ 






lOTABLE tOTABLE 










IOTABLE 








eer | _ ec 
















IOTABLE lOTABLE 






INACTIVE 
10 ENTRY 






1OTABLE 


Figure 2-5. I/0 Queues and Subqueues 
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The supervisor I/O queues (MPXIOQ and SELIOQ) include an active queue 
and a number of inactive or "pending" subqueues. Each element in the 
active I/O queue represents an I/O operation which is active ona 
particular nonshared I/O subchannel. There is only one element in the 
active I/O queue for a given nonshared I/O subchannel. The active I/0 
queue is ordered according to ascending numerical I/0 subchannel 
address. Chained to each active I/0 queue element there are inactive 
elements for any operations waiting to be performed on that same 
nonshared I/O subchannel. The queue element chains are dynamic; the I/0 
handler adds, inserts and removes elements as required. 


Queuing takes place in the subroutine DMTIOMRQ in module DMTIOM in the 
RSCS supervisor. 


QUEUING ACTIVE I/O ELEMENTS When the requested I/O operation is for a 
presently idle I/O subchannel, an I/O element representing the request 
is built and chained into the active I/O queue (in its I/0 subchannel's 
humerical address position). The I/O operation is then started by 
branching to subroutine IOSTART in module DMTIOM. 


QUEUING PENDING I/O ELEMENTS When the requested I/O operation is for an 
I/O subchannel that presently has an I/O element enqueued on the active 
I/O queue, the nonshared subchannel is busy (active), and the new I/0 
request cannot be started immediately. In this case, an I/O element 
representing the request is built and enqueued on the subchannel's 
inactive I/0 subqueue. Then control is passed to the dispatcher module 
DMTDSP in the supervisor. 


Starting an I/O Operation 


I/O operations are started by subroutine IOSTART in module DMTIOM in the 
RSCS supervisor. It attempts to start the I/O for a newly enqueued 
active queue entry. If it receives a condition code 0, the operation 
started successfully, and DMTIOM passes control to the dispatcher nodule 
DMTDSP in the supervisor. If the I/O cannot be successfully started, it 
branches to subroutine IODISMIS to terminate the operation with an 
error. 


Handling I/O Interrupts 


I/O interrupts are handled by subroutine DMTIOMIN in module DMTIOM in 
the RSCS supervisor. It locates the active I/0 queue element of the 
device that issued the interrupt, and updates the contents of the 
element and the status information in the requestor's I/0 table. If the 
interrupting I/O is still running (status incomplete), it passes control 
to the dispatcher module DMTDSP in the supervisor. If the I/O is 
complete, it branches to the IODISMIS subroutine to dequeue the 
interrupting device's I/O request element. 


If the DMTIOMIN subroutine finds no active I/0 queve element for the 
interrupting device, it scans the I/O asynchronous exit queue to locate 
a request for asynchronous I/0 exit for the interrupting device. If 
such a request is found, control is passed to the requestor's exit 
routine. Otherwise, the interrupt is ignored, and control is passed to 
the dispatcher. 
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The subroutine IODISMIS in module DMTIOM in the RSCS supervisor removes 
the active I/0 request queue element specified by the routine that 
branches to it. It calls the POST routine to signal I/O completion to 
the requesting task, It rechains the remaining I/0 request queue 
elements. If there is an inactive I/O queue for the just-detected 
entry's nonshared I/O subchannel, it makes the first inactive entry 
active by chaining it into the active queue, and branches to the IOSTART 
subroutine in DMTIOM. 


INTERRUPTION HANDLING 


Supervisor service routines handle three kinds of interruptions: 
external interruptions, SVC interruptions, and I/O interruptions. 


In RSCS, supervisor routines use the SVC (SUPERVISOR CALL) to suspend 
the execution or dispatching of a task when that supervisor routine 
received control. On an SVC interruption in RSCS, DMTSVC is entered. 
DMTSVC saves the status of the executing task and passes control to the 
calling supervisor routine in supervisor execution mode. 


RSCS handles external interruptions from tasks by searching for 
asynchronous exit requests supplied by tasks. When a request with a 
code matching the external interruption code is found, its asynchronous 
exit is taken; otherwise, the external interruption is ignored. 


I/O interruptions are handled by the RSCS I/O manager. When an active 
I/O request causes an I/O interruption, the status of the I/O request is 
updated to reflect the new information. Otherwise, a search is made for 
an asynchronous exit request for the interrupting device. When one is 
found, the asynchronous exit is taken. Otherwise, the interruption is 
ignored. 


Special Message Interruption Handling 


VMCF (Virtual Machine Communications Facility) external interrupts are 
used to pass CP Special Messages to RSCS. When one of these interrupts 
occurs, control is passed to DMTREXCF which disables RSCS for other VMCF 
interrupts and posts the VMCF synch lock for DMTREX processing. OMTREX 
moves the pertinent VMCF header information and Special Message text to 
the RSCS defined buffer (REXREQ). Control is then passed to DMTCMX for 
Special Message processing which consists of validity checking the 
Special Message text and performing the indicated RSCS command. DMTCMHX 
then returns control to DMTREX which enables RSCS for VMCF external 
interrupts. 


RSCS SPOOL FILE FORMAT 


RSCS uses the CP spool file facilities of VM/370. The spool file 
records are one page (4096-byte) blocks that contain data records and 
control records. The data records are punch card or print line images, 
and appropriate CCWs. The control records are linkage records and tag 
records, and the special headers and trailers on files from non-RSCS to 
non-RSCS systems. 
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CP Spool Data Records 


—— <<< 


Each spool logical record (card or print line) is stored as one CCW that 
moves data (READ or WRITE), a TIC to the following CCW, and the full 
data record. Space is left at the end of each buffer so that a SENSE 
command can be inserted to force concurrent channel end and device end. 
For card punch channel programs there is an additional back chain field 
that points to the card previously punched so that error recovery for 
punch equipment checks can back up one card. The only exception to the 
format of READ/WRITE-TIC-Data is in buffers of files directed to the 
printer. In this case, immediate operation code CCWs (skips and spaces) 
have their suppress data transfer flag (skip) bit set to one, and are 
followed by the start of the next record. 


CP Spool Buffer Linkage 





In addition to the data and CCWs contained in each 4096-byte spool 
buffer, the first two doublewords contain CP-supported forward and 
backward links to the next and previous buffers in the file. This 
two-way linkage allows the file to be backspaced or restarted from any 
point at any time. Also, it means that if I/0 errors are encountered 
while reading one buffer, the file is put in system hold status. If 
purged, all buffers except those in error are released. The two-way 
chain allows this control of the file while preventing fragmentation by 
allowing pages to be assigned and released individually regardless of 
their ownership. 


CP Spool Taq Record 


The first spool buffer of an output spool file contains a special 
CP-supported data record called the tag record. This record immediately 
follows the two doublewords containing the forward and backward buffer 
linkage pointers, The tag record allows WM/370 users to specify 
information to be associated with spool files that they generate. The 
information is entered via the CP TAG command, although the tag record 
is not considered a spool file data record and is not printed or punched 
as part of the spool file. However, the contents may be interrogated 
with the CP TAG QUERY operator command. 


The format of the tag record is a NOP CCW, followed by a TIC to the next 
CCW and a 136 byte data field. To differentiate the tag record from an 
immediate control CCW (no TIC-data sequence) independently of the 
command code, the skip bit (bit 35) in the CCW has the following 
convention: 


Bit 35 = 0 for NOP CCW, TIC, data (tag record) 
= 1 for control CCW (immediate command) 
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The tag record is a user information record, and RSCS as a "user" 
defines for its own use a special format of data_in the tag records. 


Whenever a file that is received on a link and spooled is to be 
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processed (forwarded) by another line driver, RSCS prefaces the tag data 
with a three character string, C'S&F', called a store and forward flag, 
that identifies to the RSCS file acceptor function a tag written by 
RSCS. 


A tag with a store and forward flag has more information than the tag 
written by CP when a virtual machine user spools a file to PSCS. (The 
CP-written tag contains the operands that the virtual machine user 
supplies, in RSCS-specified syntax, for each file spooled to RSCS from a 
local virtual machine). 


Non-RSCS Control Records 


The basic OS/NJE transmission unit is a job. RSCS handles each job 
transmitted from an NJE system as an individual file. Within the job 
are control statements: job header, data set header on each data set in 
the job, job trailer. To accommodate these control cards as unit record 
data records within the CP spooling discipline, RSCS converts them to 
NOP records (command code X'03' in their CCWs) while they are within a 
V¥M/370 system, and attaches each job's routing information on a tag. 
When forwarding them on an RSCS-to-OS link, the line driver removes the 
tag and reconstructs the NOP control records as OS control statements. 


If NJE jobs are punched or printed on real devices within the VN/370 
realm, or are read by virtual machine spool readers, the NOP records are 
discarded and do not appear as garbage data within the real data. 


VIRTUAL STORAGE MANAGEMENT 


The supervisor virtual storage service routine DM#TSTO handles requests 
by tasks for main storage. When a task requests main storage, DMTSTO 
reserves page(s) of storage for it. Main storage is freed directly by 
task prograas. 


DMTQRQ manages requests for free elements of the supervisor status 


queue. Supervisor routines call DMTQRQ to reserve and release 
supervisor status queue elements. 


RSCS Basic Functions 


This section describes the major functions of RSCS. It is to help you 
locate the module that contains the code for an operation within an RSCS 
function. The function descriptions describe the sequence of operations 
and the modules and tasks they occur in. The descriptions assume an 
understanding of supervisor services such as task dispatching, 
task~-to-task communication, task synchronization, and I/O management. 


RSCS CONFIGURATION AND STARTUP 


Loader 


The RSCS dynamic loader (DMTCRE) loads text files directly from CMS 
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disks, using the reentrant CMS read access method in REX module DMTCOM. 

The loader restricts the program to be loaded to a single CSECT and does 
not resolve external references. Multiple module RSCS tasks are merged 

into a single CSECT text file prior to loading, using the RSCS preloader 
under CMS. 


Se Se eS eS SY ST ee 


The three initialization modules are DMTINI, DMTMIN, and DMTIRX. DMTINI 
performs IPL disk load write and read operations. DMTMIN is an MSUP 
module that performs all initialization functions independent of 
particular task level programming. DMTIRX is a REX task module that 
performs all initialization related to specific RSCS functions. 


Initial loading of RSCS is performed by DMKLDOOE LOADER from the virtual 
card reader. When initial loading is complete, control passes to 
DMTINI, which functions as a stand-alone routine. The operator is asked 
for instructions, and RSCS is normally written in IPLable format to the 
system residence disk. On subsequent IPL from disk, DMTINI reads the 
disk and reloads RSCS into storage. When DMTINI has completed its 
function, control passes to DMSTMIN. 


DMTMIN begins by initializing its own base register and the fixed 
address fields in low storage. It determines the size of virtual 
Machine storage by referencing each storage key until an addressing 
exception occurs, and then DMTMIN copies itself to the last page in 
storage. From its new location at the end of storage, DMTMIN builds the 
MSUP storage allocation map, MAINMAP, according to storage size, 
starting at the beginning of the originally loaded DMTMIN module. 
Immediately following the end of the storage map, the supervisor queue 
is built and chained into a single free element queue. The mininun 
number of supervisor queue elements is computed as two for each page of 
Bain storage, and is extended through to the end of the last storage 
page required for the minimum count. All of the storage in use by MSUP 
at this point is reserved by placing X'FF' in the storage map entry for 
each page. Finally, the initial task (REX) is created by dequeuing a 
free supervisor queue element, building the initial task element in it, 
enqueueing the new task element as the task queue, and reserving a 
single page of storage at xX'10000' for the initial task. Task 
processing is begun when DMTMIN completes by passing control to the MSUP 
dispatcher. The storage used by DMTMIN remains unreserved, and is 
normally used to load the first task dynamically started by DMTIRX 
(AXS). 


DMTIRX is entered immediately the first time REX is dispatched by MSUP 
as the initial task. Initially, DMTIRX copies itself to the highest 
possible page boundary address (e.g., X*'E000') before the start of REX 
at X*10000', sets its base registers to the new address, and branches to 
label IRXGO in the new copy. The task name ‘REX' is placed in the 
initial task element, and RSCS-defined task vectors are set in the MSUP 
low storage TVECTORS fields. The virtual machine user ID being used is 
retrieved from CP by a hypervisor call (DIAGNOSE X'00') and is set in 
its field in DMTCOM. Next, the operator console and system residence 
DASD device are identified by a similar hypervisor call (DIAGNOSE 
X'24"), and I/O parameters for these devices are initialized. Next, the 
CMS Access Control Areas in DMTREX and DMTCRE are initialized as 
follows: 


1. If the RSCS system disk is standard CMS 800-byte format, no 
special initialization is required and the routine is exited. 

2. When the RSCS system disk is in CMS Enhanced Disk format, the 
GETSUPAG routine in DMTCOM is called to obtain virtual storage for 
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The RSCS location definition, link tables, default start parameters, 
route table, port table, tag slots, and installation variables are 
initialized from the RSCS directory by a call to GENVNET. The 
installation specification tables and the tag slot queue are built 
beginning at the original starting address of DMTIRX, such that DMTIRX 
and DMTINI (which are no longer needed) are overwritten. 


On return from GENVNET, the total storage from the beginning of the REX 
task to the end of the installation variabie tabies is computed and 
reserved for the RFX task in the MSUP storage map. Next, the operator 
console I/O table in DMTREX is initialized, the console and timer 
asynchronous interrupt exits are initialized by a call to the ASYNREQ 
(DMTASY) entry to MSUP. At this point, RSCS prepares for communicating 
with the CP Special Message Facility by issuing a VMCF AUTHORIZE command 
and setting bit 31 on in Control Register 0. The AXS and LAX tasks are 
loaded by calis to DMTCRE, virtual storage is obtained for the DIAG 8 
response buffer via a call to GETSUPAG, the initial active link count is 
set to zero, the maximum number of startable links is computed and set 
based on the virtual storage available, the program check new PSW is set 
to enter the program check manager in REX (DMTREXPI), the initial 
messages are generated and issued by a call to DMTNGX, and control is 
passed to DMTREXIN, At this point, REX executes the PROFILE RSCS 
initial command sequence if present and not suppressed by the IPL 
parameter keyword 'NOPROF'. Finally, AXS is notified via an alert call 
from REX that initialization is complete, queued spool input files are 
accepted by AXS, and normal RSCS processing begins. 


RSCS SYSTEM DISK ACCESS 


The RSCS system disk is a CMS mini disk created, updated, and maintained 
by installation personnel working under CMS. The RSCS access method 
Supports the RSCS system disk as shown in Figure 2-6. 


SS SS ee 
| { Current CMS Disk Format | Enhanced Disk Format* | 
Sn Ss en nn 
| Device | | | | I 
| Type | Block Size: 800 { 1K | 2K | 4K { 
1 I Ht 


{ 2314 J} Yes { Yes | Yes | Yes | 
{ 3330 {| Yes { Yes | Yes | Yes | 
{| 3340 | Yes | Yes | Yes | Yes | 
{ 3350 | Yes { Yes | Yes | Yes | 
{ 3310 | No | Yes | Yes | Yes | 
{ 3370 | No | Yes | Yes | Yes | 


{* This support may be obtained in VM/370 Basic Systems | 
| Extensions Program Product, Release 2; it does not | 
{ support 800-byte blocks. All of the support for Enhanced | 
I I 


Disk Format is new function for RSCS Networking. 
|e | 


Figure 2-6. RSCS System Disk Format 
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In the algorithms used to access DASDs in blocksizes other than 800 
bytes, the RSCS access method permits one level of indirect addressing 
(one level of pointer blocks). This enables the RSCS user who creates 
the RSCS system disk under CMS of the VM/370 Basic Systems Extensions 
Program Product, Release 2, to have the characteristics shown in Figure 
2-7. 


CS re ar a ee Ne TE ee eee ee Ne ge eee 
| Block { Maximum Number | Maximum Number | Maximum Size | 
| Size { of Files | of Data Blocks | of File 

ne i Pa Se 
1 1K Bytes | 4,096 | 256 | 256K Bytes | 
| 2K Bytes | 16,384 I 512 ! 1024K' Bytes | 
{ 4K Bytes | 65,536 | 1024 i] 096K Bytes | 


een cer cc eee enn nn ee SE | 


Figure 2-7. RSCS System Disk Characteristics 


The operation of this support within RSCS is transparent to the RSCS 
user. This support is neither invoked nor used by the RSCS user. An 
installation's options for formatting the RSCS system disk under CMS may 
be determined from the preceding table. 


To locate a file, given the file name and file type, this support usees 
the addressing scheme shown in Figure 2-8. 


RSCS FILE HANDLING FUNCTIONS 


RSCS file handling is described in the following overview section, 
followed by descriptions of the link table, link activation, and the 
input and output of files by the line drivers. Note that there is a 
description of the MULTI-LEAVING protocol used by several line drivers, 
in Appendix A of this publication. 


Scenario of RSCS File Handling 


This section is a high level description of the file handling that RSCS 

provides. The description uses Figure 2-9 to show RSCS systems in three 
VM/370 nodes processing a routed file from an originating node, through 

an intermediate node, to a destination node. 


To fulfill its networking file handling capabilities, RSCS has functions 
to: 


Ts Receive files spooled to it from virtual machine users on the local 
VM system where it resides. (See Figure 2-10, path marked with 
circled 1.) 


2- Receive files from adjacent nodes. (See Figure 2-10, paths marked 
with circled 2.) 


3. Analyze and send received files to local virtual users. (See 
Figure 2-10, path marked with circled 3.) 
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Figure 2-8. Locating a File on the RSCS System Disk (Part 1 of 2) 
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The procedure for locating a file is as follows: 


1. A check is made to determine whether the disk is in EDF format or 
the current format. If the volume label identifier field is 
"CMS=", it is in the current format; if the identifier field is 
"CMS1", it is in the Enhanced Disk Format. 


2. If it is in the current format, processing continues as in the 
VNET PRPQ. 


3. If it is in the Enhanced Disk Format, the first File Status Table 
Block (FSTB) is referenced by the Directory Origin Pointer (DCP). 


4. From the first FST in the FSTB, the number of pointer levels is 
obtained. If the number of pointer levels is 0, the current and 
only FSTB is searched for the FST containing the given filename 
and filetype. 


5. If the number of pointer levels is 1, the File Origin Pointer 
(FOP) points to the pointer block. Each entry in the pointer 
block points to an FSTB. The end of a partially filled pointer 
block is denoted by zeros. 


6. Using the pointer block entries, FSTBs are accessed and scanned 
until the required FST containing the given filename and filetype 
is found. 


7. If the number of pointer levels is 1, the FOP points to a pointer 
block. Each entry in the pointer block points to a data block. 
The end of a partially filled pointer block is denoted by zeros. 


8. If the number of pointer levels is 0, the FOP points to the one 
and only data block for this file. 


9. Using the pointer block entries, the data blocks are accessed 


until the file has been read. 
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Figure 2-8. Locating a File on the RSCS System Disk (Part 2 of 2) 


4. Analyze and forward files to adjacent nodes. (See Figure 2-10, 
paths marked with circled 4.) 


In this scenario, the network is very simple: three VM/370 systems 
(VM1, VM2, and VM3) each with an RSCS system running, and each with 
telecommunication links. Systems VM1 and VM3 each have a user virtual 
system, CMS, running. (This is an example only; CMS does not have to be 
the user machine.) The scenario has six steps, A through F, described 
below. 


(A) User Archie on the CMS virtual system at location VM1 is sending a 
file to user Bob on the CMS virtual system at location VM3. To do 
so, Archie issues the CP commands: 


SP OOD TO RSCS1 
TAG DEV OOD VM3 BOB 
PUNCH filename filetype 


These commands tell CP to spool the virtual punch output from 
Archie's job, place the specified tag data on the spool file, and 
give the spool file to the local virtual system called RSCS1. This 
is an instance of the first type of basic RSCS file handling 
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(B) After CP does this, RSCS1 Looks at the tag information on the spool 
file. RSCS1 determines that the file is destined for VM3, and, to 
determine this location's specifications for forwarding files to 
VM3, consults its routing tables and link tables. It transmits the 
file on the link to VWM2. This is an instance of the fourth type of 
basic RSCS file handling function described below. 


(C) On the WM/379 system VM2, the RSCS2 virtual machine receives the 
file and spools it. RSCS2 sees that the destination information in 
the file's tag data does not contain this location's (VM2*s) locid, 
and tells VWM2 CP to give it to RSCS2. (It spools the file to 
itself in order to transfer the handling of the file from the RSCS 
receiving function to the RSCS sending function.) Then it tells 
RSCS1 that the file is successfully received, allowing RSCS1 to 
release and effectively erase its copy of the file. This is an 
instance of the second type of basic RSCS file handling function. 


(D) CP informs RSCS2 of the new spool file's presence. RSCS2 performs 
the same forwarding function (type 4) described for RSCS1's 
forwarding of the file. In this instance, RSCS2's link table 
directs it to send the file on the VM3 link. 


(E) At system VM3, the RSCS3 virtual machine receives the file and 
spools it. RSCS3 sees that the file's tag data specifies user Bob, 
on the CMS system, on the VM3 location (locid) as the destination. 
RSCS3 tells VM3 CP to spool the file to virtual machine user Bob. 
RSCS3 issues a console message to Bob, informing him of the file. 
RSCS3 tells RSCS2 that the file is successfully received, 
terminating this transmission and allowing RSCS2 to release the VH2 
spool copy of the file, 


(F) CP passes the RSCS message and its own notification of the file's 
arrival to Bob. 
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NW | 
| swe!) A | say | pf sx | 


<= ey 5 — 


lo @ © 


A B C D E F 


CP 


Figure 2-9. Scenario of RSCS File Handling Functions 
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Receiving a File from a Local Virtual System 


This is handled by CP in the same way that it does for any other virtual 
machine under its control. Spool reader files are queued for input to 
virtual machines, and are retained by CP until they are read or purged. 
Files are normally read by virtual machine simulated card readers, but a 
number of direct hypervisor calls (simulated DIAGNOSE instructions) are 
provided by CP to allow virtual machine systems to interrogate and 
manipulate and read the input spool file queue. 


Receiving a File from a Remote 


jn 


ysten 


1. The line driver recognizes the start of an arriving file and issues 
a message to notify the RSCS operator. 


2. RSCS spools the file to itself (spool file opened for output). 


ae The line driver issues a GIVE request to DMTAXS requesting for 
a spool file to be opened for output (request code=11). The 
“request arrival" synch lock of DMTAXS gets posted. 


b. DMTAXS gets dispatched at AXSCYCLE, tests the "request 
arrival" synch lock, finds that is on, and then branches to 
AXSACCPT. 


cs DMTAKE is called to take the GIVE request. 


d. REQXEQ is called to decipher the request code (11). It 
determines the address of the appropriate subroutine 
(OPENOUT), and branches to it. 


e. OPENOUT scans the link's queue of active output tag slots to 
determine if the file is already being processed. If so, the 
I/O area (TAKE response buffer) is returned to the line driver 
and the appropriate open code ("old -file found") is posted 
before control is returned to AXSCYCLE. 


f. If not so, OPENOUT: (1) calls GETLINK to check if the line 
driver has a locally defined link; (2) calls GETSLOT to get a 
free tag slot, and (3) calls GPAGEREQ to get a page for a new 
I/O area. 


g. The tag information supplied in the GIVE request is moved into 
the new tag slot. 


h. DEFINE is called to internally define a virtual punch by means 
of a call to CP. 


i. OPENOUT moves an asterisk to the virtual machine destination 
ID field (TAGTOVM field of the tag element) to indicate 
spooling the punch to RSCS. 


j- OPENOUT calls VSPOOLP to effect a CP SPOOL punch command. 

k. OPENOUT initializes the I/O area (pointed to by register 7) by 
building the device I/O table. The tag element is then placed 
at the beginning of the link's active output tag queue. 

l. In response to the line driver's GIVE request, OPENOUT returns 


the address of a new I/O area and inserts the appropriate open 
post code before returning control to AXSCYCLE. 
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3. The iine driver gets dispatched and issues subsequent punch 
commands as the file is received. 


4G. When EOF is reached, the line driver closes the virtual punch. 


ae The line driver issues a GIVE request to DMTAXS, specifying a 
Closing of the output file (request code = '12'). 


b. DMTAXS gets dispatched at AXSCYCLE which eventually calls 
CLOSEOUT. 


Cc. CLOSEOUT locates the active output tag slot and dequeues it 
from the active output queue. 


ad. CLOSEOUT updates the tag element with information obtained 
froma the line driver's tag prototype. 


e. CLOSEOUT determines if the file is destined for this location 
or to a remote location. This is done by comparing the 
TAGTOLOC field with the LINKID field of the local location's 
link table. 


f. If the fields are not equal, the file is to be stored and 
forwarded. VTAGD is called to assemble the appropriate tag 
command text and to issue the CP TAG command. VTAGD inserts 
the "S&F" flag into the command text; the command text 
contains the following: 


S&F TAGTOLOC TAGTOVM TAGPRIOR TAGINLOC TAGINVM TAGINTOD 
TAGORGID TAGCNTL 


g- VSPOOLP is called to issue CP SPOOL punch OFF to reset the 
punch to no-spool mode. 


h. VCLOSEO.is called to issue CP CLOSE punch. 
i. DETACH is called to issue CP DETACH punch. 


a FPAGEREQ is called to free the file I/0 area's virtual storage 
page. 


k. FREESLOT is called to free the tag. 


Le The close post code is set and Control is returned to 
AXSCYCLE. 


Sending a Received File to a Local Virtual Systen 








Upon receiving a file from a remote node, the line driver enters the 
file into its local CP spool system, as described previously. However, 
when the line driver closes the spool file, AXS determines that either 
the file is to be forwarded to a remote location (in which case the file. 
remains spooled to RSCS), or the file belongs to a local virtual machine 
(in which case the file is spooled to the local virtual machine's 
reader). Therefore, the sequence of events is like Steps 1 through 4 of 
the preceding paragraph with a difference, starting at Step 4-f, as 
follows: 


1. The line driver recognizes the start of an arriving file and issues 
a message to notify the RSCS console operator. 


rae RSCS spools the file to itself (spool file opened for output). 
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The line driver gets dispatched and issues subsequent CP spool 
punch commands. 


When EOF is reached, the line driver closes the virtual punch. 


a. The line driver issues a GIVE request to DMTAXS, specifying a 
closing of the output file (request code = '12'), 


b. DMTAXS gets dispatched at AXSCYCLE which eventually calls 
CLOSEOUT. 


oa CLOSEOUT locates the active output tag element and dequeues it 
from the active output queue. 


d. CLOSEOUT updates the tag element with information obtained 
from the line driver's tag prototype. 


Ge CLOSEOUT determines if the file is destined for this location 
or to a remote location. This is done by comparing the 
TAGTOLOC field with the LINKID field of the local location's 
link table. 


£. If the file is destined for this node (local locid same as 
TAGTOLOC field), a further check is made as to whether the 
file is to go to a local virtual machine or to a remote 
workstation. 


With the TAGTOVM field as a search argument, GLINKREQ is 

called to see if a link with a link ID that matches TAGTOVM is 

defined at the location. If so, the file is spooled to RSCS 

and enqueued for transmission to the workstation. Otherwise, 

the file is spooled to the specified local virtual machine. 
The file is punched to the local virtual machine user. 


ae CLOSEOUT calls VTAGMSG to put user notification message into 
the spooled file's tag area. 


b. VSPOOLP is called to point the reader of the virtual machine 
(whose ID is stored in TAGTOVM) to the spooled file. 


Ce VCLOSEO is called to issue CP CLOSE punch. 
d. DETACH is called to issue CP DETACH punch. 


e. FPAGEREQ is called to free the file I/O area's virtual storage 
page. 


f. FREESLOT is called to free the tag. 


g. The close post code is set and control is returned to 
AXSCYCLE. 


Sending a Received File to a Remote Node 











CP notifies RSCS of the spool file on RSCS's virtual reader. 

ae A simulated asynchronous device end I/O interrupt is given to 
the lowest virtual device address reader that is both idle and 
eligible to read the file, RSCS's device address X'001'. 


b. The I/O interrupt handler (DMTIOM/IOASYNCH) selects the 
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AXSASYIO calls DMTPST to post the "file arrival" synch lock, 
and then returns control to the dispatcher. 


When DMTAXS gets dispatched, it executes at AXSCYCLE, which 
detects that the "file arrival" synch lock has been posted, 
and causes a branch to ACCEPT. 


accepts the file. 
DMTAXM/ACCEPT internally issues a "CLOSE RDR HOLD" to CP. 


ACCEPT calls GSUCCESS to read a spool file block and tag 
information. (GSUCCESS uses the VM/370 DIAGNOSE X'14! 
instruction, subcode X'FF', to do this). The address of the 
spool file block and tag information is returned to the buffer 
specified in the DIAGNOSE X*14" instruction.) 


ACCEPT calls TAGFIND and scans the tag queue of every link 
defined in the link table to look for a match with the tag 
just read. 


If there is a match it indicates that the spool file block and 
tag just read was already in process. TAGFIND returns to 
ACCEPT with condition code 0, and ACCEPT reads the next tag 
and spool file block. 


If there is no match, the spool file is eligible for 
processing; TAGFIND returns to ACCEPT with condition code 3. 
ACCEPT then checks the validity of the data in the tag read. 


ACCEPT extracts the destination information from the tag and 
calls the nodule GROUTREOQ to determine the link on which to 
enqueue the file. 


If GROUTREQ fails to find a link that has been defined for the 
destination, ACCEPT checks if the file has been marked "S&F" 
(store-and-forward) and if it originated from RSCS. 


If the file has been flagged S&F (previously done when the 
file was closed after RSCS received it and spooled it) and if 
there is no link defined for it: (1) the spool file is purged 
from VWM/370, (2) AXSM103, which issues a message request to 
DMTREX, is called to notify the spool file's originator, and 
(3) the next spool file is read from RSCS's reader. 


If the file was not flagged "S&F" (that is, the file 
originated locally), ACCEPURG examines the location ID of the 
file's originator. If the originating location ID (TAGTOLOC) 
is the same as the local LOCID (described by the LINKID field 
of the first link table entry in the link table chain), the 
file must have originated from VM/370's real card reader if 
the file origin userid is equal to the userid of the RSCS 
virtual machine. In this case the file is purged and a 
message issued to the originator. 


If the origin location ID is not the local LOCID, the file is 
transferred to the originator by internally issuing the CP 
TRANSFER command, and a message is sent to the originator. 
If a link is found, GETSLOT is called to get a free tag slot. 


If no free tag slot is available: (1) the file is left alone 
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in the spool, (2) the count of the number of pending files is 
incremented, (3) AXSM102 is called to issue the "file pending" 
message, and (4) the next spool file block and tag is read. 


TAGGEN is called to move the contents of the tag and spool 
file block into the free tag slot to generate a new tag 
element. 


TAGPLACE is called to enqueue the tag slot, by transmission 
priority and file size, to the tag queue of the link selected 
by GROUTREQ. 


The LFLAG bits in the link's link table are checked to see if 
the link is already processing a file. If so, ACCEPT proceeds 
to read the next spool file. If not so, the ALERT bit is 
reset and an ALERT is issued to the link's line driver and 
control is returned to the dispatcher. 


The line driver reads the spool file for transmission to the next 


node. 


ae 


Ce 


d. 


ee 


f. 


(Spool file is opened.) 


The line driver issues a GIVE request to DMTAXS, requesting to 
open a file for input (request code = X'01'). The "request 
arrival" synch lock for DMTAXS gets posted. 


When DMTAXS gets dispatched, AXSCYCLE finds that its "request 
arrival" synch lock has been posted and thus branches to 
AXSACCPT, which calls DMTAKE to take the GIVE request. REQXFQ 
is then called. REQXEQ deciphers the request code (X'01"'), 
determines the appropriate processing routine (OPENIN), and 
branches to it. 


OPENIN searches for active files for the link specified in the 
request by scanning its active input tag queue. If such a 
file is already in process, that file is returned to the 
caller. 


OPENILNK finds the link table for the link that sent the open 
request. This is done by scanning for a link table that 
contains a link ID that matches the requesting link's ID. 


Call UNPEND to enqueue as many pending files for the line 
driver as possible: (1) Call TAGFIND to search for a pending 
file for this link, (2) call TAGGEN to generate a tag slot, 
(3) call TAGPLACE to enqueue the new tag slot on the link's 
queue, (4) update the pending file count, and (5) issue a 
message if a pending file is missing. 


Call FILSELEC to select a file to be read from the link's tag 
queue. FILSELEC scans the tag queue, pointed to by LINPUTQ in 
the line driver's link table. It dequeues the first tag found 
for a file that is not in hold status and that matches the 
file class setting in the caller's link table. A message is 
issued if the file is missing from CP's spool system. 


Call GPAGEREQ to get a page of storage for the I/O area. The 
address of this storage is stored in the TAGBLOCK field of the 
selected tag slot. 


Call DEFINE to internally define a virtual reader by means of 
a call to CP. 


Call VSPOOLR to internally issue the "SPOOL READER CLASS *" 
command. 
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OPENIN issues the DIAGNOSE XK'1%"' command to make the file 
described in the tag slot the next in the reader just defined. 
Then it opens the file by issuing another DIAGNOSE x¥'14! 
command to read the first spool page buffer of the file into 


the I/0 area. 


OPENIN enqueues the tag slot at the beginning of the active 
input tag queue. 


AS a response to the original oper request by the line driver 
to DMTAXS, OPENIN returns to the line driver the address of 
the I/O area (buffer) containing the spool file records. The 
line driver reads the rest of the file with successive 
DIAGNOSE X'14* calls. 


A branch is made to OPENEXIT which inserts the appropriate 
open post code before giving control back to AXSCYCLE. The 
return from TAKE posts the GIVE table in the line driver 
storage. 


4. The line driver is dispatched and starts transmitting spool file 
records to the remote location. EOF is recognized when a DIAGNOSE 
X¥'14" returns EOF on the input spool file. 


5. The line driver receives positive acknowledgement from the 
receiving location after the file is completely transmitted. The 
file is purged or held depending upon the close options. (Spool 
file is closed.) 


Ae 


COMMAND 


The line driver issues a GIVE request to DMTAXS, requesting 
input file closing (request code = X'02'). The “request 
arrival" synch lock for DMTAXS gets posted. 


DMTAXS gets dispatched at AXSCYCLE and finds that its "request 
arrival" synch lock has been posted, and branches to AXSACCPT. 


DMTAKE is called to take the GIVE request. 


REQXEQ is called to decipher the request code (Xx'02"), 
determines the name of the appropriate subroutine (CLOSIN), 
and branches to it. 


CLOSIN scans the active input tag queue for the tag of the 
file to be closed. When the tag is found, it is removed from 
the active input tag queue. 


CLOSIN examines the AXSREQ field of the AXS monitor control 
area and decides whether the file is to be held or purged from 
the spool system. (AXSREQ contains a copy of the line 
driver's request element. ) 


CLOSIN frees the I/O areas used, sets the appropriate close 
post code, and returns control to AXSCYCLE. 


AND MESSAGE HANDLING FUNCTIONS 


Command and message flow within RSCS is handled by a store and forward 
mechanism with differences from file store and forwarding. Some 
differences are: 


e Commands and messages are not stored on spool files, and are lost if 
the RSCS node handling them goes down. 
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e Routed commands and messages are not forwarded if the necessary link 
is undefined, 


inactive, or not connected. 


Figure 2-10 shows the steps used in handling RSCS commands and messages. 
The circled numbers in the diagram correspond to the following 
descriptions. 
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emote System Command 
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When a line driver receives a routed command or message from a remote 
system, it builds a Routing Request Element and passes it in a GIVE 
request to supervisor module DMTGIV, which builds a Give Queue Flement, 
posts the DMTREX synch lock (at the end of the task save area), and 
marks the REX task dispatchable. 


When REX is dispatched and finds its GIVE/TAKF synch lock posted, it 
issues a TAKE, examines the request, and because it is a Routing Request 
Element, passes it to the routing processor module DMTRGX. 


Remote Workstation Command Input to RSCS (Path 2) 


When a command is from a remote workstation (SMI or NPT), the line 
driver builds a Command Fequest Element and passes it ina give request 
to supervisor module DMTGIV, which builds a Give Queue Element for it, 
posts the DMTREX Give/Take synch lock (at the end of its task save 
area), and marks the REX task dispatchable. 


When REX is dispatched and finds its Give/Take synch lock posted, it 
issues a Take request to supervisor module DMTAKE. The TAKE processor 
locates the GIVE Queue Element for this task, and passes the Command 
Request Element to the taking task, REX. The task examines the request 
and because it is a Command Request Element passes it to the command 
executor module DMTCMX. 


Commands £ Local Execution (Path 3) 








DMTREX passes command request elements for local execution to DMTCMX. 

These elements may originate from a remote workstation line driver, a 

command sent to RSCS through the Special Message Facility, or built by 
DMTREX from a command entered at the RSCS operator console. 


Routing Request Element for This Location (Pa 4) 





DMTREX passes routing request elements from remote NJI/NJE systems to 
DMTRGX. 


If the destination locid in the Routing Request Element contains the 
local location's locid and it is a command request, DMTRGX forwards it 
to command executor processor module DMTCMX. If it is a message for the 
local location's locid and no destination userid is specified, DMTRGX 
constructs a DMTRGX170 console message and forwards it to the message 
processor module, DMTMGX. But, if it is a message for this locid and 
there is a userid specified in the routing information, the following 
happens: 


ae If there is a linkid defined matching the specified userid 
(cemote workstation), RGX moves the destination userid into 
the destination locid field and constructs a DMTRGX170 message 
element, which it passes to DMTGxX to issue. 


b. If there is no linkid matching the specified userid, the 
userid must be for a local virtual machine or the RSCS 
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operator. DMTRGX formats a DMTRGX171 message element and 
forwards it to DMTMGX to issue to the local virtual machine 
specified in the destination userid. 


or Another System (Path 5) 


If the destination locid in the Routing Request Element is not the local 


location's locid, DMTRGX calls GROUTREQ in DMTCOM to determine the path 


to the destination locid. 
connected, RGX passes the 
link's line driver task. 

connected, RGX either (a) 
discards it, or (b) fora 
message to the originator 


If the link is defined, active, and 
element to it with an alert request to the 
If the link is undefined, inactive, or not 
for a message type Routing Request Flenment, 
command type Routing Request Element, issues a 
via DMTMGX, giving the reason for inability to 


process the command any further. 


Local Commands Originating from NJI/NJE Systems (Path 6) 


See ee ee ————— 





DMTREX passes command request elements for local execution to DMTCMY. 
These elements originate from a remote NJI/NJE systen. 





DMTRGX passes to DMTMGX message request elements that are constructed 
from message type routing request elements received from remote NJI/NJE 
systems, as described for Path 4. 


The message routine builds messages, using text supplied in module 
DMTMSG and variables supplied in the message buffer, and forwards then 
to the appropriate recipients. Messages issued as part of 
locally-executed commands go to DMTMGX. 


The contents of each message built at this location are edited into one 
of four formats. Fditing is under control of the EMSG setting in CP. 
The DIAGNOSE command X'SC' invokes this editing. Depending upon the 
EMSG setting, the message is one of: 


Message 
Message 
Message 
Neither 


header and message text 
header only 

text only 

header nor text 


Line Driver Handling of Command Alert Elements (Path 9) 











Line drivers receive alert elements, containing line driver Command 

Alert Elements. The two general classes of line driver alert elements 
are: those that specify internal line driver commands that one of the 
line driver's processors executes, and those that specify commands or 
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The second byte of a line driver command alert element, called the 
Function Code, identifies the element type. All X'Bx' requests are 
forwarding (transmitting) commands containing data for remote locations: 


X'BO" is from a locally-entered or remote workstation-entered CMD 
command; 


X¥'*B1* is from a locally or workstation-entered MSG command; 


X'B2* is an RSCS-issued routed message built by this location's 
DMTMGX module and directed to a remote location. 


When DMTCMX issues an alert (Path 9 in Figure 2-7) for an 
internally-executed line driver function (such as backspace), the 
function code in the line driver command alert element is one of: X'80* 
through X*84", x*90", xX*91", or X*AQ®. 


When a line driver is able, it accepts any alert immediately. It posts 
its appropriate synch lock, and stacks all X'B1' and X'B2' requests by 
calling the REX task, module DMTCOM, routine PMSGREQ. All line drivers 
except DMTSML and DMTPOW do the same with X'BO' requests. 


When a line driver is busy (already processing a command), it rejects 
any internal line driver commands. DMTSML and DMTPOW also reject X'BO! 
requests when they are busy. 


The line driver mainline program sees the synch lock that indicates one 


Or more stacked requests, and handles the requests by calling the REX 
task, module DMTCOM, routine GMSGREQ. 


Forwarding Locally-Generated Messages on Links (Path 10) 





When a locally-originated message, formatted and edited by DMTMGX, is to 
be forwarded to a remote location, DMIMGX passes it to the appropriate 
line driver in a Message Alert Element. 


Nn 


Issuing Messages to Local Virtual System Use 


ee ee eee he ae ee 


(Path 11) 











DMTMGX issues messages to local virtual system users by means of the 

DIAGNOSE X08" instruction, which executes a CP MSG command. If the 

user that the message is directed to is not logged on, the message is 
purged. 


Issuing Messages to the Local RSCS Operator's Console (Path 12) 








DMTMGX issues messages to the local RSCS operator by a BALR to the 
PMSGREQ routine in module DMTCOM, where the message is queved for 
issuing by the DMTREX module's console message routine. 
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When the line driver issues a message as part of executing a request, it 
does so by a GIVE request to DMTREX, passing a Message Request Element. 


Local RSCS Operator Command Input (Path 14) 


— ——S ES 


A command issued at the RSCS operator's console may be a request for a 

function on the local system or at a remote system, or it may specify a 
message to a local virtual machine user or to a remote operator console 
or virtual machine user. 


The asynchronous interrupt generated by the RSCS console ATTENTION key 
causes control to pass to the console I/O asynchronous exit routine, 
DMTREXCI, in the REX task, module DMTREX. The message or command issued 
by the operator is passed to DMTCMX. 


Receiving Messages from Local Virtual System Users (Path 15) 


A command issued by any virtual machine to an RSCS virtual machine must 
be sent through the Special Message Facility. It may be a request for a 
function at a local or remote RSCS system, or it may specify a message 
to a remote virtual machine console. 


The asynchronous interrupt generated by the Virtual Machine Communica- 
tion Facility (VMCF) causes control to be passed to the asynchronous 
VMCF external interrupt routine, DMTREXCF, in the RFX task module 
DMTREX. The message (MSG) or command (CMD) issued by the Special 
Message sender is then passed to DMTCMX for processing. 


RSCS ACCOUNTING 


An accounting record is generated by module DMTAXA, when called fron 
CLOSEIN or CLOSEOUT in module DMTAXM, each time an input or output spool 
file is closed. Accounting records are generated for input files only 
if the spool file originated locally. Accounting data is obtained from 
the spool file's tag block. Time and date information is obtained from 
vVM/370 CP through the DIAGNOSE instruction. The DIAGNOSE X'4C! 
instruction is used to punch the assembled accounting record to VM/370. 


Line Driver Functions 


THE LINK TABLE 


A line driver task can only exist for an entry in the link table. 
During RSCS initialization, a link table entry is built for each link 
defined in a LINK statement in the RSCS directory. (The first entry in 
the link table is reserved as a container of the local locid.) The 
parameters in the LINK statement are recorded in its link table entry. 
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e Use the DEFINE command to alter any of the parameters in a link table 
entry that is not active (does not have a line driver task running for 
it). 


e Use the DEFINE command to add new link definitions. (There are 
sixteen empty link table entries after RSCS initialization.) 


e Use the DELETE command to remove a link definition, leaving its 
previous link table entry empty. 


The link table has two functions: it contains the parameters of defined 
links, as described above, and when the link has been started, it 
contains. running data for its line driver task. See Section 5 of this 
manual for details of the Link Table Entry contents. 


LINK ACTIVATION: LOADING AND STARTING A LINE DRIVER TASK 


The objective of line driver task startup is to provide a task to 
perform the operations of one of the links specified in the link table. 
This is done by obtaining the storage required by the line driver 
module, loading the line driver module into that storage, and causing 
its initialization code to execute. The line driver's initialization, 
in turn, configures the line driver to the characteristics specified for 
its link. 


The START command specifies a link to be started, and includes any 
optional parameters to override parameters in the link table entry. 

(The overrides are irplemented only for this activation of the link; 
they do not replace the permanent "default" parameters in the link table 
or in the RSCS DIRECT entry.) 


Loading the Line Driver, Function Description 











1. Process the START command in REX module DMTCMX. 


a. DMTCMX validates the command parameters. It builds the link 
table "active" parameter entries, using the parameter default 
values in the link table, unless an override value is 
specified in the START command. 


b. Issue an ALERT to the LAX task to validate the line address 
specified for this link. If it is a switchable port, it must 
have an entry in the switchable port table (built at 
initialization from RSCS DIRECT data set PORT statement 
specifications). It must be a supported device type for the 
line driver to be loaded. If it is a leased line, it must not 
be already in use by another active link. 


C4 LAX task completes the ALERT request for line validation by 
passing to DMTCMX a return code that specifies the result of 
the line validation. 


d. When the REX task is next dispatched, DMTCMX evaluates the 
validation return code and executes appropriate routines for 
the conditions in the code. If validation found the line to 
be satisfactory, DMTCMX calls REX module DMTCRE to create the 
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line driver task. 


2. Load the line driver module specified for this link, using REX 
module DMTCRE. 


ae Call REX module DMTCOM, routine RCMSGET, to read the first 
text record of the module. On return, locate in that record 
the module's size, 


b. Find in MAINMAP (the byte-map of free and in-use virtual 
storage pages) the location of the number of contiguous free 
storage pages required for the module. 


Ce. Pass control to the supervisor storage manager module, DMTSTO, 
to reserve the desired pages in MAINMAP. 


d. When the REX task is redispatched, DMTCMX constructs the line 
driver module in the reserved storage with a series of 
requests for the module text records, performed by the RCMSGET 
routine in the DMTCOM module in the REX task. 


e. Initiate startup of the line driver as a task by passing 
control to the supervisor module DMTASK, giving the task name 
in register 0 and the address of the task save area in 
register 1. (The task name default is the first four 
characters of the linkid if there was no override value in the 
START command for the task.) If there is no task by this name 
already running, DMTASK proceeds to start this one. It builds 
a task queue entry for it, marking it dispatchable. Control 
passes to the REX task module DMTCMX, which issues an operator 
message that the link is started, and turns on the ACTIVE and 
CONNECT flags in the line driver task's link table. 


f.. When the newly started task's line driver task gets 
dispatched, its initialization code executes. 








Line Driver Task Initialization, Function Description 





A line driver module is loaded and started as a task as part of starting 
a link, as described above. 


Whenever a task is dispatched, the register contents and the PSW in the 
task's save area are loaded, and control passes to the instruction 
address that was in the PSW. 

When the line driver task is dispatched after being loaded, the PSW 
assembled in its save area contains the address of its initialization 
routine. Register 0 is preinitialized during loading with a count of 
the parameter information, register 1 with the address of the parameter 
information, and register 2 with the task's link table address. 


Every RSCS line driver contains, in its initialization routine code, 
logic for the following, with exceptions as noted: 


ae Save the address of its link table in its own storage. 
b. Copy its linkid into its own storage. 


Ce Copy its local RSCS location's locid (contained in the linkid 
field of the first link table entry) into its own storage. 


d. Scan the parameter information, decode the parameters, and 
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ee Build the file request element that this link will pass in its 
GIVE request element to AXS when it initiates or terminates 
processing of an input or output file. 


f. Build tag prototype for this task, containing initial constant 
values (such as linkid) for any tag queue entry AXS will build 
for this task's files. 


gd. Issue asynchronous exit requests for interrupts (usually alert 
interrupts) that this link should receive through DMTASY. 


h. Some line drivers need teleprocessing buffers. (The VMB line 
driver contains its own buffer). They call the REX module 
DMTCOM, routine GPAGEREQ to find the required number of pages 
in MAINSAP and get the storage manager module, DMTSTO, to 
reserve ther. 


In the NJI line driver, the DMTNIT module issues the buffer 
storage requests. 


5 i If the link has a BSC line, disable the BSC adapter, set its 
mode, and enable it. If the link has a channel-to-channel 
adapter, test its status by a SENSE command to determine the 
state of the remote systen. 


SHL LINE DRIVER FUNCTION DESCRIPTIONS 


The SML line driver (DMTSML) provides binary synchronous communication 
(BSC) line protocol for programmable remote stations. DMTSML contains 
four types of routines: 


e Processors (routines) that execute the functions required by the 
processing modes. 


e An input/output routine that accepts and transmits data on the BSC 
line. 


e A function selector routine that dispatches one of the processors when 
a request for services is received. 


e Buffer blocking and deblocking routines. 


Figure 3-6, "Program Organization for the SML Line Driver Task," shows 
the functional relationships among these routines. 


With programmable remote stations, the SML line driver operates as a 
host (HOST mode) or as a remote job entry station (RJE mode). In HOST 
mode a remote station may submit jobs to VM/370 and receive print and 
punch output from VH/370. In RJE mode, VM/370 may send jobs to a remote 
batch system for processing and receive print and punch output from the 
remote batch system, Figure 2-11 shows the types of data flowing to and 
from RSCS via the SML Line Driver. 


Section 2: Method of Operation - Line Driver Functions 57 


Licensed Material - Property of IBM 


HOST Modes: 


VM/370 

a | REMOTE WORK STATION 
RSCS | ——— 
——___—_—_—__| Jobs 


{ 

| 

i | < 

{| | SML Line oe | 
| | Driver in | 

{ | HOST mode | 
| 
| 

| 


Bae 
{ 


{ PRINT/PUNCH Output 


ee ee 


a 


RJE Mode 


VM /370 

REMOTE BATCH SYSTEM 
{ RSCS i cc 7 
eae Jobs I 
i | ————— 
{ | SML Line { | 
! | Driver in { | 
{ {| RJE mode | { PRINT/PUNCH Output f 
i] < 
| 
I 


| 


ee ee ee) 


Figure 2-11. SML Line Driver Data Flow to Remote Stations and Systems 


SML Processors 





The SML program provides eight "processors," or routines, designed to 
handle the eight functions required to support the processing modes. 
Figure 2-12 is a list of the SML processors, the processing modes they 
support, and a brief statement of their functions. The DMTSML program 
determines its mode of operation by testing a byte, SMLSYS, which is set 
during SML line driver initialization. SMLSYS set to one of the 
following values: 


X'80' - RJE mode, HASP 


X"'4O" = RJE mode, ASP 
X*20" - RJE mode, VS1I/JES 
X'10* - HOST node 
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| Processor | Mode | Function | 


none az Fi hs 
| S$CRTN1 { Both | Processes MULTI-LEAVING control records: | 
| | | permission to transmit, request to { 
] | { transmit, and SIGNON control records. | 
{ SPRIN1 | RJE | Processes print file records from remote | 
| I | stations and passes them to the VM/370 spool] 
{ | | systen. | 
-——____—_—__—___-- 1 Oh 
j SURTN1 j RJE j Processes punch file records from remote i 
| | | stations and passes them to the YM/370 spool] 
| I { systen. { 
| $JIRTN1 { HOST {| Processes job file records from the remote | 
| | | station and passes them to the VM/370 spool | 
l \ | system. 

$WRIN1 Both | In HOST mode, passes command request | 


I | 

| | | elements via DMTMGX to DMTCMX. In RJE mode, | 
{ 1 | passes message request | 
1 | | elements to the RSCS operator's console. | 
t-—___—___+------___ + —-___---- 4 
| $RRTN1 | Both {| Receives records from the VM/370 spool | 
| i {| system for transmission to remote stations. | 


-—____ | -—_____ —___ _——__—_———————— ene eee 
{ CMDPROC | Both | Executes local commands passed by DMTCMX; | 
| | | passes messages and commands to remote | 
I | | stations. \ 
| MSGPROC {| Both | Sends messages to remote stations. | 


erences cnet ensteelseneeneenentntn en nntanee ne peepee te cena 


Figure 2-12. SML Function Processors 


SML Command Processor: $WRIN1 





When a command is transmitted from a remote station to RSCS, SML 
receives the command and coordinates processing of the command with 
Supervisor routines and the REX task command module DMTCMX. 


The SML command processor, $WRTN1, processes a command request from a 
remote station by passing a command request element to the RFX task 
(module DMTCMX) via a GIVE request. DMTCMX then determines whether the 
command should be executed by DMTCMX, DMTAXS, or the line driver. If 
the command is to be executed by the line driver, it is passed back to 
SML via an alert request. SML routine CMDPROC then executes the 
command. 


The SML line I/O handler routine, COMSUP, controls communications on the 
BSC line for SML. This routine receives data from the BSC line and 
passes it to the deblocker routine ($TPGET). COMSUP also sends data 
(which has been blocked by the blocker routine, $TPPUT) to a remote 
station. COMSUP also acknowledges receipt of data over the line using 
the standard BSC line control characters. 
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SML Function Selector Routine: $START 








The $START routine is entered when SML is required (by either a remote 
station or a virtual machine) to perform a function. This routine 
selects a function to execute by using a "Commutator Table", a list of 
synch locks, and "Task Control Tables". 


Each processor except MSGPROC and CMDPROC has a TCT (task control table) 
which contains necessary control information. Also, contained within 
the TCT is a branch instruction to the appropriate processor. 


The SML commutator table is a branch table consisting of branch (BC) and 
no-operation (NOP) instructions. The targets of the branch instructions 
are the TcTs for the eight processor routines, COMSUP, and $ITPGET, each 
of which performs a specific function. When the service of a routine is 
not required, the commutator table entry for that routine is a NOP 
instruction. When the function of the routine is required, the NOP 
instruction in the commutator table entry for that routine is replaced 
with a Branch instruction, thereby “opening a gate" in the commutator 
table. 


The $START routine cycles through the commutator table, falling through 
any NOP instructions and taking any branches. Control is passed in this 
way to any routine whose gate in the commutator table is open. 


When the routine completes the function requested, it "closes" its gate 
in the commutator table by replacing the Branch instruction with a NOP 
instruction. $START continues cycling through the commutator table, 
taking any open branches. 


Initially after line driver startup, the commutator table branch 
instruction for reading a card, $RCOM1, is not a NOP. This allows the 
line driver to immediately read an available file from CP spool as soon 
as the line driver is started. In this case, processor $RRTN1 gives an 
OPEN request to DMTAXS to start reading a file from CP spool. If there 
is no file to be opened, $RRTN1 "closes" the commutator table gate for 
$RCOM1. 


When the bottom of the commutator table is reached, $START tests a 
series of synch locks to see if any have been posted, signifying a 
request for an SML function. If any synch lock is posted, $START opens 
the commutator table gate for the requested routine and goes to the top 
of the commutator table to start cycling through it again. 


If the bottom of the commutator table is reached and there are no posted 
synch locks, SML discontinues processing by issuing a wait request via a 
call to the Supervisor module DMTWAT, waiting on a list of the synch 
locks. When any of the synch locks is posted, $START receives control, 
opens the appropriate gate, and starts cycling through the commutator. 








Block and Deblock SML Teleprocessing Buffers: $TPPUT and $TPGET 





Data received over the BSC line is placed in one of four teleprocessing 
(TP) buffers. The size of TP buffers is specified by a START command 
parameter and can be up to 1017 bytes. 


Data contained in TP buffers is deblocked into "tanks," which are unit 
buffers of a specific size used to deblock the larger TP buffers. There 
are 15 tanks; these are allocated as they are needed by processors. The 
size of tanks is determined by MULTI-LEAVING control bytes. 
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When an SML function has been requested, the data must be either blocked 
for transmission (if it is data for a remote station) or deblocked for 
processing (if it has been received from a remote station). 


$TPGET receives data from a BSC line (via the COMSUP routine) and 
allocates tanks to output processors as they are needed. 


$TPPUT receives tanks from input processors, blocks the data in these 


tanks into TP buffers, and gives control to COMSUP to transmit the 
buffers over the line. 
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Assume a file to be sent to a remote node has been spooled to RSCS. The 
events that follow are: 


1. RSCS is informed of the presence of the file. DMTAXS accepts it by 
issuing an alert to the appropriate link's line driver task 
(DMTSML). 


2 DMTSML's exit routine (ASYNEXIT) posts DMTSML's reader device synch 
lock (RDEVSYNC), and control is returned to the dispatcher. 


3e DMTSML is dispatched and the function selector routine, $START, is 
entered. $START finds that the synch lock RDEVSYNC has been posted 
and opens the gate for card reading ($RCOM1) in the commutator 
table (see description of $START, above). 


4. With the gate opened, $RRTN1 reads the VM/370 spool file, deblocks 
(reconstructs) it into original record sizes, reblocks them into 
tanks for transmission, and gets them transmitted: 


ae $RRTN1 issues a GIVE to DMTAXYS, requesting a spool file be 
opened and requesting a virtual reader be defined for the line 
driver itself. 


b. On successful return from DMTAXS, $RRTN1 extracts tag 
information from the spool file block (SFB) to determine the 
required transmission type (e.g., print or punch), and the 
transmission mode (HOST or RJE). This information is used to 
prepare the transmission record control byte (RCB), 
transmitted with each block of data. 


If the file was not successfully opened, the gate in the 
commutator table is closed and control returns to $START. 


Cs $TPOPEN is called, requesting permission to transmit (STPOPEN 
does this by transmitting a Request Control Record). If 
permission is granted, the message DMTSML146I is issued to 
indicate that the file is being transmitted. 


d. VMDEBLOK is called. It reads VM/370 spool file blocks or 
pages into page buffers, and issues subsequent reads as 
records in the buffers are used up. The records are deblocked 
according to the CCW information embedded with the data during 
spooling. VMDEBLOK returns to the caller a deblocked record 
that is placed in a 136-byte field (RCTTDTA1) within the tank. 


e. The record given by VMDEBLOK is combined with the proper 


MULTI-LEAVING transmission control bytes_in preparation for 
transmission. 
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Es The record and its transmission control bytes are passed to 
$TPPUT via a call. $TPPUT compresses the record into a "line" 
that complies with the MULTI-LEAVING transmission protocol. 
The compressed line is packed into a teleprocessing buffer. 
When the buffer is filled, it is queued to the $0UTERUF chain 
for processing by COMSUP. 


g. COMSUP initiates the actual I/O activity to transmit TP 
buffers. COMSUP dequeues buffers from $0UTBUF for 
transmission and calls DMTIOMRQ to initiate the I/0 operation. 
COMSUP's gate is opened when the adapter synch lock, ADAFCB 
gets posted by an I/O interrupt. 


h. The EOF condition is eventually reached as VMDEBLOK reads the 
file from CP spool, in response to requests from $RRIN1 for 
more records to send. AS soon as EOF is reached: (1) Message 
DMTSMLIG7I is issued, (2) a GIVE is issued to DMTAXS to close 
and purge the file, (3) $TPPUT is called to transmit a null 
record to inform the receiver of the EOF condition, (4) the 
gate in the commutator table is closed, and (5) control is 
returned to the start of $RRTN1 to process another file. 


SML File Receive (Spool Output File Incoming 


———e oe 


n Link) Function 


This process starts with COMSUP's gate being opened when its synch lock 
ADAECB gets posted by an adapter asynchronous I/O interrupt. COMSUP 
examines the BSC control characters on the TP buffers received. The 
three kinds of control characters received are: 


1. DLE-ACK, which specifies there is no block transmitted with this 
buffer. 


2% DLE-STX, which specifies start of text. This acknowledges that 
RSCS received a buffer containing data, and that RSCS, in response, 
can send an output buffer. 


a3 NAK, which specifies that the buffer sent by RSCS to a remote 
location was not correctly received. 


The control character significant to COMSUP when receiving a file is the 
DLE-STX. Upon receipt of this character from the TP line, COMSUP starts 
the process of receiving a file by chaining the received buffer to the 
input buffer chain, and opening the gate for $TPGET in the commutator 
table. 


The general sequence of events that occur is as follows: 

Vs $TPGET is entered; it deblocks received telecommunication buffers 
into tanks, selects the appropriate processor, queues the tank to 
the selected processor's TCTTANK queue. $TPGET operates as 
follows: 


a. Get a buffer from the $INBUF queue and look for a matching TCT 
to attach the buffer to by comparing RCBs. 


b. Get a tank to decompress a buffer into. 
Cy Decompress the buffer into the tank. 


d. Chain the tank to the TCTTANK queue for the processor 
selected. 
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e. Open the commutator gate for that processor. 


2 The selected processor is entered when $TPGET returns to the 
commutator. The processor selected is one of the following: 


$PRTN1: This routine processes print files. It dequeues tanks queued to 
itself by COMSUP, obtains an output spool device, and outputs the tanks 
to a virtual printer as follows: 

ae Call $GETTWK to obtain a tank. 


b. Call DMTAXS to request for an output spool file to be opened 
and a printer device defined. 


C. Set up the carriage control using information contained in the 
SRCB. 


d. Call DMTIOMRQ to print a record to the VM/370 spool file. 

e. Call DMTAXS to close the spool file when EOF is reached. 

f. Return to the commutator (S$START). 
SURTNI: This routine processes punch files. It dequeuves tanks queued to 
itself by COMSUP, obtains an output spool device, and outputs the tank 
to a virtual punch as follows: 


ae Call $GETTNK to obtain a tank. 


b. Call DMTAXS, requesting an output spool file be opened and a 
punch device defined. 


Ce Call DMTIOMRQ to punch a record to the VM/370 spool file. 
d. Call DMTAXS to close the spool file when EOF is reached. 
e. Return to the commutator ($START). 
<< : 
it by COMSUP, brates an output spo 
virtual punch as follows: 
ae Obtain a tank from $GETTNK. 


b. Call DMTAXS to have a spool file opened and a punch device 
defined. 


Cs Call $USREXIT to validate the information on the job file's ID 
card and to save any other text information on the ID card. 
This text information represents user commands, which will be 
passed to the REX task for processing. $USREXIT also fills in 
the JCTTOVM field of the processor's TCT. 

d. Call DMTIOMRQ to punch the job file records to the spool file. 

e. Call DMTAXS to close the spool file when EOF is reached. 


f. Return to the commutator ($START). 
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POW LINE DRIVER FONCTION DESCRIPTIONS 


The POW line driver (DMTPOW) provides binary synchronous communication 
(BSC) line protocol for remote VSE/POWER systems. DMTPOW contains four 
types of routines: 


e Processors (routines) that execute the functions required by the 
processing modes. 


e An input/output routine that accepts and transmits data on the BSC 
line. 


e A function selector routine that dispatches one of the processors when 
a request for services is received. 


e Buffer blocking and deblocking routines, 


Figure 3-6, "Program Organization for the POW Line Driver Task," shows 
the functional relationships among these routines. 


Figure 2-13 shows data flowing to and from RSCS via the POW Line Driver. 


VM/370 

| ae | VSE/POWER SYSTEM 

J RSCS j ct 
{| emo, | Jobs/Commands ! | 
11 Oe | 
| ! | | | 
1 | POW Line ! € PRINT/PUNCH Output {f{ | 
| | Driver ' <—-——— 1 
1 | | | | 
1 | If Messages { { 
| <---> I 
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1 { ici a eae e eee ee e 


Figure 2-13. POW Line Driver Data Flow to a VSE/POWER Systen 


POW Processors 


The POW program provides eight "processors," or routines, designed to 
handle the eight functions required. Figure 2-14 is a list of the POW 
processors and a brief statement of their functions. 
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f Y ' 


| Processor I Function { 
ee 
{| $CRIN1 {| Processes MULTI-LEAVING control records: | 


t { permission to transmit, request to | 
| | transmit, and SIGNON control records. | 


}+--—_—____—_-———~ 

| $PRTN1 | Processes print file records from the | 
| | remote VSE/POWER system and passes then | 
| { to the VM/370 spool. | 
-—_———_—_—_————_-——__——_ OO 


{ $SURTN1 { Processes punch file records from the | 
| { remote VSE/POWER system and passes then | 
i j to the V#/370 spool. ! 


SS Se 
{ SWRIN1 © {| Writes received VSE/POWER commands to the | 
| | RSCS operator's console. . | 


SS SSS SS SS 
{ SRRIN1 {| Receives records from the ¥M/37C0 spool i 
{ | system for transmission to the remote { 
| | VSE/POWER systen. | 


_——_- 

| SMRIN1 | Writes received VSE/POWER messages to the | 
| | RSCS operator. | 
| CMDPROC | Executes local commands passed by DMTCMX; 1 
{ { passes commands to the remote VSE/POWER I 
{ { systen. { 
| MSGPROC | Sends operator and system messages to the I 


{ { remote VSE/POWER systen. { 
| een ee | 


Figure 2-14. POW Function Processors 
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The POW line I/O handler routine, COMSUP, controls communications on the 
BSC line for POW. This routine receives data from the BSC line and 
passes it to the deblocker routine ($TPGET). COMSUP also sends data 
(which has been blocked by the blocker routine, $TPPUT) to the remote 
system. COMSUP acknowledges receipt of data over the line using the 
standard BSC line control characters, 


OW Function Selector Routine: $START 


The $START routine is entered when POW is required by a remote VSE/POWER 
system to perform a function. This routine selects a function to 
execute by using a "Commutator Table", a list of synch locks, and "Task 
Control Tables". 


Each processor except MSGPROC and CMDPROC has a TCT (task control table) 
which contains necessary control information. Also, contained within 
the TCT is a branch instruction to the appropriate processor. 


The POW commutator table is a branch table consisting of branch (BC) and 


no-operation (NOP) instructions. The targets of the branch instructions 
are the TCTs for the eight processor routines, COMSUP, and $TPGET, each 
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of which performs a specific function. When the service of a routine is 
not reguired, the commutator table entry for that routine is a NOP 
instruction. When the function of the routine is required, the NOP 
instruction in the commutator table entry for that routine is replaced 
with a Branch instruction, thereby "opening a gate" in the commutator 
table. 


The $START routine cycles through the commutator table, falling through 
any NOP instructions and taking any branches. Control is passed in this 
way to any routine whose gate in the commutator table is open. 


When the routine completes the function requested, it "closes" its gate 
in the commutator table by replacing the Branch instruction with a NOP 
instruction. $START continues cycling through the commutator table, 
taking any open branches. 


When the bottom of the commutator table is reached, $START tests a 
series of synch locks to see if any have been posted, signifying a 
request for a POW function. If any synch lock is posted, $START opens 
the commutator table gate for the requested routine and goes to the top 
of the commutator table to start cycling through it again. 


If the bottom of the commutator table is reached and there are no posted 
synch locks, POW discontinues processing by issuing a wait request via a 
call to the Supervisor module DMTWAT, waiting on a list of the synch 
locks. When any of the synch locks is posted, $START receives control, 
opens the appropriate gate, and starts cycling through the commutator. 


POW Asynchronous Alert Exit Routine: ASYNEXIT 


— ee aaa. 





This is an alert exit entered by DMTSIG when a message or command has 
been entered for the POW line driver to process, or, a reader file has 
arrived for transmission to the remote system. It operates as follows: 


1. Test if the alerting task is DMTAXS or DMTREX. 


2s If the alert is from DMTAXS, call DMTPST to post the RDEVSYNC synch 
lock and exit. 


35 If the alert is from DMTREX, determine if it is for a command or 
message. 


4, If it is a command and a previous command is not being processed, 
accept the command, post CMDECB, and exit. Otherwise, indicate to 
DMTREX that the command is refused, and exit. 


5. If it is a message, call MFI in DMTCOM to stack the message for 
later processing, post MSGECB, and exits 


Block and Deblock POW Teleprocessing Buffers: $TPPUT and $TPGET 


—— OO  — —— =. eo 








Data received over the BSC line is placed in one of four 512-byte 
teleprocessing (TP) buffers. 


Data contained in TP buffers is deblocked into "tanks," which are unit 
buffers of a specific size used to deblock the larger TP buffers. There 
are 15 tanks; these are allocated as they are needed by processors. 


When a POW function has been requested, the data must be either blocked 
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for transmission {if it is data for a refote VSE/POWER system), or 
deblocked for processing (if it has been received from a remote 


VSE/POWFR system). 


$TPGET receives data from a BSC line (via the COMSUP routine) and 
allocates tanks to outfut processors as they are needed. 


$TPPUT receives tanks from input processors, blocks the data in these 
tanks into TP buffers, and gives control to COMSUP to transmit the 
buffers over the line. 


POW Control Record Processor: SCRIN1 





This routine performs the processing required for MULTI-LEAVING control 
records. It functions as follows: 


1. Get a control tank from the queue; if none are available, close the 
$CRIN1 gate in the commutator and exit to the next commutator 
entry. 


2< If a tank is available, remove it from the queue and open the gate 
for $TPGET to get another tank. 


3. Based on the bits contained in the RCB, branch to the appropriate 
sub-processor. The following table lists the routines that can be 


entered. 
Oa pf oe ee ee a a ee a he ee ee 
| RCB { Routine | Reason for Entry { 


jt tH 


{ 80 l MCO [| Not supported; exit | 
| 90 I MC1 { Start function request | 
| AQ | MC2 | Start function permission | 
j BO | MCc3 { Not supported; exit | 
{ co | MC4 { Not supported; exit | 
| DO | MC5 | Not supported; exit | 
| EO | MC6 { Not supported; exit { 
| FO | MC7 ] General control record | 


ee ee en en | 


MC1- This sub-processor is entered when VSE/POWER transmits a 
"Request to Initiate Function" record. The function to be 
started is contained in the SRCB. A search is made of all 
the TCTs to find a match on the function code. If none is 
found, exit. If a matching TCT is found, the RCB in the 
received record is changed to X'AO' (Permission Granted) and 
$TPPUT is called to send the record to VSE/POWER. 


MC2 - This sub-processor is entered when VSE/POWER transmits 
"Permission Granted" to a "Request to Initiate Function" from 
RSCS. A search is made of all the TCTs to find a match on 
the function code contained in the SRCB. If none is found, 
exit. If a matching TCT is found, its gate in the commutator 
is opened to allow it to begin processing. 


MC7 - This sub-processor is entered when a general control record 
is received by RSCS. This type of control record contains a 
sub-function code in the SRCB. This code is an 
identification character between A and Z (EBCDIC). Only A 
(initial signon) is supported. DMTPOW checks the record for 
"PSIGNONxxx" or "PCOMPLETE"., If PSIGNON, $TPPUT is called to 
transmit “PREADYnnn". If PCOMPLETE, message DMTPOW9OSI is 
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issued and a switch is set to indicate signon complete. 
Otherwise, error message DMTPOWSI02E is issued and the line 
driver is deactivated. 


Pow File Send (Transmit Input Spool File on Link) Function 





Assume a file to be sent to a remote node has been spooled to RSCS. The 
events that follow are: 


1. 


68 


RSCS is informed of the presence of the file. DMTAXS accepts it by 
issuing an alert to the appropriate link's line driver task 
(DMTPOW) . 


DMTPOW's exit routine (ASYNEXIT) posts DMTPOW's reader device synch 
lock (RDEVSYNC), and control is returned to the dispatcher. 


DMTPOW is dispatched and the function selector routine, $START, is 
entered. $START finds that the synch lock RDEVSYNC has been posted 
and opens the gate for card reading ($RCOM1) in the commutator 
table (see description of $START, above). 


With the gate opened, $RRTN1 reads the VM/370 spool file, deblocks 
(reconstructs) it into original record sizes, reblocks them into 
tanks for transmission, and gets them transmitted: 


ae SRRTN1 issues a GIVE to DMTAXS, requesting a spool file be 
opened and requesting a virtual reader be defined for the line 
driver itself. 


b. On successful return from DMTAXS, $RRITN1 extracts tag 
information from the spool file block (SFB) to determine the 
spool file type (console, print, or punch). If the file is 
not a punch file, message DMTPOWSGOE is issued and the file is 
purged. 


If the file was not successfully opened, the gate in the 
commutator table is closed and control returns to $START. 


Ce $STPOPEN is called, requesting permission to transmit ($TPOPEN 
does this by transmitting a Request to Initiate Function 
Record). If permission is granted, the message DMTPOW1T46I is 
issued to indicate that the file is being transmitted. 


d. VMDEBLOK is called. It reads VM/370 spool file blocks or 
pages into page buffers, and issues subsequent reads as 
records in the buffers are used upj The records are deblocked 
according to the CCW information embedded with the data during 
spooling. VMDEBLOK returns to the caller a deblocked record 
that is placed in a 136-byte field (RCTTDTA1) within the tank. 


e. The record given by VMDEBLOK is combined with the proper POWER 
MULTI-LEAVING transmission control bytes in preparation for 
transmission, 


f. The record and its transmission control bytes are passed to 
$TPPUT via a call. $TPPUT compresses the record into a "line" 
that complies with the POWER MULTI-LEAVING transmission 
protocol. The compressed line is packed into a teleprocessing 
buffer. When the buffer is filled, it is queued to the 
SOUTBUF chain for processing by COMSUP. 


g- COMSUP initiates the actual I/O activity to transmit TP 
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Lor 
e I/O operation. 
lock, ADAECB 


s from $oOUTBU 
transmission and calls DMTIOMRQ to initiate t 
COMSUP's gate is opened when the adapter sync 


gets posted by an I/0 interrupt. 


om pr ny 


h. The EOF condition is eventually reached as VMDEBLOK reads the 
file from CP spool, in response to requests from $RRTN1 for 
more records to send. As soon as EOF is reached: (1) Message 
DMTPOW147I is issued, (2) a GIVE is issued to DMTAXS to close 
and purge the file, (3) $TPPUT is called to transmit a null 
record to inform the receiver of the FOF condition, (4%) the 
gate in the commutator table is closed, and (5) control is 
returned to the start of $RRTN1 to process another file. 


POW File Receive Function 


This process starts with COMSUP's gate being opened when its synch lock 
ADAECB gets posted by an adapter asynchronous I/O interrupt. COMSUP 
examines the BSC control characters on the TP buffers received. The 
three kinds of control characters received are: 


1. DLE-ACK, which specifies there is no block transmitted with this 
buffer. 


2 DLE-STX, which specifies start of text. This acknowledges that 
RSCS received a buffer containing data, and that RSCS, in response, 
can send an output buffer. 


3. NAK, which specifies that the buffer sent by RSCS to a remote 
location was not correctly received. 


The control character significant to COMSUP when receiving a file is the 
DLE-STX. Upon receipt of this character from the TP line, COMSUP starts 
the process of receiving a file by chaining the received buffer to the 
input buffer chain, and opening the gate for $TPGET in the commutator 
table. 

The general sequence of events that occur is as follows: 

Ps $TPGET is entered; it deblocks received telecommunication buffers 
into tanks, selects the appropriate processor, queues the tank to 
the selected processor's TCTTANK queue. $TPGET operates as 
follows: 


a. Get a buffer from the $INBUF queue and look for a matching TCT 
to attach the buffer to by comparing RCBs. 


b. Get a tank to decompress a buffer into. 
Cc. Decompress the buffer into the tank. 


d. Chain the tank to the TCTTANK queue for the processor 
selected. 


e. Open the commutator gate for that processor. 


2e The selected processor is entered when $TPGET returns to the 
commutator. The processor selected is one of the following: 


$PRTIN1: This routine processes print files. It dequeues tanks queued to 


itself by COMSUP, obtains an output spool device, and outputs the tanks 
to a virtual printer as follows: 
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Call $GETTNK to obtain a tank. 


Test for end-of-file. If not EOF, continue processing. If EOF 
exists and the file was previously opened, issue message 
DMTPOW145I and close the file via a call to DMTAXS. 

Otherwise, free the tank (see step g). 


Convert the "CTR" characters into a CCW opcode and remove then 
from the record. If the resultant opcode indicates a special 
VSE/POWER CCW (X'FF' or X'FD'), free the tank. 


Note: "CTR" refets to the VSE/POWER command code that is 
contained in the first two bytes of all data transmitted from 
VSE/POWER to RSCS and in commands and messages sent from RSCS 
to VSE/POWER. The CTR is the expanded hex format (xX'OB! 
becomes FOFB) of the CCW opcode that will be used to print the 
data. For commands, CTR is 00. 


If the opcode is a NOP (X'03'), this indicates the possibility 
of a VSE/POWER MLX record in the data. If the record is not 
MLX1, free the tank. Otherwise, close the file via a call to 
DMTAXS (if it was open), 


Note: MLX records are internal VSE/POWER control records that 
allow VSE/POWER to send JECL information to another VSE/POWER 
system. These records are contained at the beginning of all 
list and punch files sent from VSE/POWER to RSCS. RSCS 
extracts the class, copy count, and number of records from the 
first of the three MLX records. These records are transmitted 
with a NOP CCW opcode (X'03') by VSE/POWER and are not printed 
or punched in the output produced by RSCS. 


Extract the output class, number of copies, and number of 
records from the MLX1 record, open the spool file via a call 
to DMTAXS, and issue message DMTPOW144T1. 


Using the CCW opcode obtained from the "CTR" characters, send 
the output line to the V8/370 spool file via a call to 
DMTIOMRQG. 


Free the tank - remove the current tank from the queue, open 
the commutator gate for $TPGET, and return to the beginning of 
the processor. 


$URTNi: This routine processes punch files. It dequeues tanks queued to 
itself by COMSUP, obtains an output spool device, and outputs the tank 
to a virtual punch as follows: 
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b. 


Ce 


Call $GETTNK to obtain a tank. 


Test for end-of-file.s If not EOF, continue processing. If EOF 
exists and the file was previously opened, issue message 
DMTPOW145I and close the file via a call to DMTAXS. 

Otherwise, free the tank (see step g). 


Convert the "CTR" characters into a CCW opcode and remove then 
from the record. 


If the opcode is a NOP (X'03'), this indicates the possibility 
of a VSE/POWER MLX record in the data. If the record is not 
MLX1, free the tank. Otherwise, close the file via a call to 
DMTAXS (if it was open). 


Extract the output class, number of copies, and number of 
records from the MLX1 record, open the spool file via a call 
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to DMTAYS, and issue message DMTPOW144T. 
Send the output line to the VM/370 spool file via a call to 
DMTIOMRQ. 


Free the tank - remove the current tank from the queue, open 
the commutator gate for $TPGET, and return to the beginning of 
the processor. 


SWRIN1: This routine writes received VSE/POWER commands to the RSCS 


operator. 


ae 


b. 


g. 


It functions as follows: 
Close the commutator gate for this processor. 
Call $GETTNK to obtain a tank. 
If no tank is available, return to the commutator. 
Remove the "CTR" characters from the incoming record. 


Set up a message buffer and issue message DMTPOWI44I via a 
call to DMTREX. 


Note: This message will contain the received VSE/POWER 
command. 


Remove the current tank from the queue and open the gate for 
$TPGET. 


Return to the beginning of the routine and try to obtain 
another tank. 


$MRIN1 This routine writes received VSE/POWER messages to the RSCS 


Operator. 


It functions as follows: 
Close the commutator gate for this processor. 
Call $GETTNK to obtain a tank. 
If no tank is available, return to the commutator. 
Remove the "CTR" characters from the incoming record. 


Set up a message buffer and issue message DMTPOW170I via a 
call to DMTREX. 


Note: This message will contain the received VSE/POWER 
message. 


Remove the current tank from the queue and open the gate for 
$TPGET. 


Return to the beginning of the routine and try to obtain 
another tank. 


POW Message Handler: MSGPROC 


This routine is entered when the MSGECB is posted by the asynchronous 
exit routine, indicating messages are in the MSG queue for this line 


driver. 


It operates as follows: 


Ve Close the commutator gate for MSGPROC. 
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2. Call MFO in DMTCOM to remove a message from the queve. If none are 
available, send FOF to VSE/POWER via a call to $TPPUT and return to 
the conmjutator. 


ae If the message is not from the system or the RSCS operator, issue 
message DMTPOW531I and return to the beginning of the routine to 
get another message. 


4. If the message was from the RSCS operator, prefix the message with 
"“DMTPOW170I from ‘linkid'". 


5. Put the message into the console tank and insert "CTR" prefix. 


6. Call $TPOPEN to send a "Request to Initiate Function" transmission 
to VSE/POWER. 


Te Call $PUT to send the actual message, then return to the beginning 
of the routine to get another messsage. 


POW Command Handler: CMDPROC 





This routine is called by $START when a wait request completes with the 
posting of the command arrival synchronization lock (CMDECB) following 
the acceptance of a command alert element from DMTREX. The command code 
table (CMDTABLE) is searched for a code matching that of the accepted 
element, and the command's processing routine is entered when a match is 
made. If no match is found, message DMTPOW531I is issued, and a return 
is made to the commutator, thus ignoring the command. The command 
processing routines are: 


SSS 
| Routine | Command Processed | 
| SETSTART | START 1 
| SETDRAIN | DRAIN { 
| SETFREE | FREE { 
| SETHOLD jf HOLD 1 
{ SETTRACE ] TRACE { 
| SETCAD | CaD i 


| a See | 


These individual command processors issue messages, set flags, and 
modify other line driver status, depending upon the particular command 
and the processing status of the line driver. When processing is 
complete, control is returned to CMDPROC which then returns to the 
comm uta tor. 


If the command specified was CMD, this indicates that DMTPOW must 
forward a command to VSE/POWER for execution. The processing is as 
follows: 


1. Verify that the command was entered by the RSCS operator; if not, 
issue message DMTPOW531I and exit. 


2. Syntax check the command text to ensure that the entered VSE/POWER 
command and its operands are supported for the RSCS-to-VSE/POWER 
connection. If not, message DMTPOWS4IE, 942E, or 943E is issued 
and an exit is made from the SETCMD routine. 


36 Put the command into the console tank, move in "CTR" and "™* ., " 
prefixes. 
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4. Call $TPOPEN to send a "Request to Initiate Function" transmission 
to VSE/POWER. 


5. Call $PUT to send the command. 
6. Call $TPPUT to send EOF. 


T* Return control to CMHDPROC which then returns to the commutator. 


Typical RSCS to VSE/POWER Line Transmissions 


=e Se 








Figures 2-15 to 2-20 show the character sequence used in the following: 





*s Signon procedure 
e Initiation of a transmission 
e Command transmission 
e Stop proced ure 
e Transmission of text in one direction 
e Transmission of text in both directions 
Coes Se a ee 
I I l ! 
{ RSCS { { VSE/POWER { 
| I | 
| [ ee eee 
| | 
{ | 
|<—_-_——_-_—-_--——-_SOH,ENQ (non—trans.) >I 
1 DLE,ENQ (transparent) { 
| I 
{ | 
1 >DLE ,ACKO———_—_____________________> ] 
i i 
I | 
I | 
[<——-SOH,STX, BCB, FCS, FCS,RCB, SRCB,* .«.PSIGNONrrr[ ,password ], | 
1 RCB,SYN, ETB <—————________________| 
I | 
| { 
{|———_——>SOH, STX, BCB, FCS, FCS, RCB,SRCB,* ..PREADYnnn, ] 
{ RCB,SYN, ET B———___________________> | 
I I 
t ! 
I< SOH,STX, BCB,FCS,FCS,RCB,SRCB,* ..PCOMPLETE, | 
! RCB,SYN, ETB< | 
J | 
| | 
| >DLE , ACKO————_____—_—__________________> | 
| A { 
{Handshaking | | 
{ v | 
iK DLE, ACKO<—_--____-_____-_______________ 
rrr = global remote identifier generated within the POWER macro. 
non = global remote identifier from the Cnnn parameter of RSCS START 


command. 


Figure 2-15. Signon Procedure 


Section 2: Method of Operation - Line Driver Functions 73 


Licensed Material - Property of IBM 


Se pe Cy... 
I I { | 
1 RSCS | | VSE/POWER | 
1 | { | 
ee | ne | 


| Request permission to initiate a function: 

I< SOH, STX, BCB, FCS, FCS, RCB, SRCB,SCB, 
| RCB, SYN, ETB< 

{ 

| Grant permission to intiate a function: 

| >SOH ,STX,BCB, FCS, FCS, RCB,SRCB,SCB, 
| RCB,SYN,ETB 








Vv 


I 

{| Data block: 

| <—__—_-_-_—____-SOH , STX,, BCB, FCS, FCS, RCB, SRCB,SCB, 

| ctr,ctr,SCB....< 

I 

{ End of stream record: 

| <<—__-_——_—_—_SOH , STX ,BCB, FCS, FCS,RCB,SRCB,SCB, 

l RCB,SYN, ET B——_————______________—__- 
I 


K———_____—_—__—_—_—_—__—_—___——_ DLE, ACK0 << -———_______________________ 


Figure 2-16. Initiation of a Transmission 


pews —_—+-__ oe 


[ I I l 
I RSCS | | VSE/POWER | 
| ! 


A 


Request permission to 
initiate a function< 


>Grant permission to 
initiate a function 


Vv 


<———-—-SOH ,STX, BCB, FCS, FCS, RCB, SRCB,SCB,ctr, ctr, SCB, 
* 4. Ccommand,SCB,RCB,SYN,ETB< 


>DLE, ACKO 


Vv 


“A 


Fnd of stream record< 


es re ees ee ges oe es ee ee ee ee es ee ee oe ee oe 
Se 


—_________-______ DLE, ACKQ 


Vv 


Figure 2-17. Command Transmission 
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os 


RSCS 


I 1 
{| VSE/POWER | 
! ! 


bee aes ree oe ee 
{ 


—— 8 oe 


| Request permission to initiate a function: 
| <—_——_______————-SOH, STX,BCB,FCS,FCS,RCB,SRCB,SCB, 
RCB,SYN, ETB< 


Grant permission to initiate a function: 
>SOH, STX,BCB,FCS,FCS,RCB,SRCB,SCB, 
RCB,SYN, ET B—————_____________"—_> 


<———-SOH, STX, BCB, FCS, FCS, RCB ,SRCB ,SCB,ctr,ctr, SCB, 
* .. PSTOP LINE[ ,E0J],SCB,RCB,SYN,ETB< 


ee eee ee Sl lr 


a ene ec eee aera aly 1 5 Py Vol G0 ee ee 


Figure 2-18. Stop Procedure 


eh oo eS Coa ee 
| | { | 
| RSCS { | VSE/ POWER i 
{ | | 1 
LJ | nee | 





{ | 
I { 
I< Request permission to initiate a function< I 
| I 
|——. >Grant permission to initiate a function >| 
{ 1 
I< text I< \ 
| { 
| >AcKO———____________.____} | 
{ line error | 
{ aa 1 
|<— | text2< | 
| v | 
i >NAK >I 
| I 
I< text2< 1 
I l 
| >ACKQ >| 
| . I 
| . | 
I< textn< | 
1 | 
>ACKO————_—_________>| 
| | 
I< End of stream record< { 
| | 
L_____________________________— > AC K 0-4 


Figure 2-19. Text in One Direction 
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ee eee 
1 ! ! | 
| RSCS | i] VSE/POWER | 


<——_——_——-Request permission to initiate a function< 


| { 
| | 
i i 
| | 
| >Grant permission to initiate a function >I 
| | 
1< text 1< | 
1 | 
| >Request permission to initiate a function >I 
| I 
I< Grant permission to initiate a function< | 
| | 
| >texta >I 
| I 
i< text 2< { 
] line error 4 | 
I >textb——_____________ | >I 
l v | 
I< NAK< I 
{ I 
{ >textb >| 
{ I 
I< text3< | 
I l 
{ >textc >I 
I | 
K—_ text 4<——_—___________________—_l 


Figure 2-20. Text in Both Directions 


NPT LINE DRIVER FUNCTION DESCRIPTIONS 


The NPT line driver (DMTNPT) provides binary synchronous communication 
(BSC) line protocol for nonprogrammable remote terminals. This allows: 


e Remote users of VM/370 to enter source decks, data, and jobs, on 
cards, into the VM/370 spool systen 


e VWM/370 to send spooled output of virtual machine sessions to remote 
card punches and printers 


e Remote stations to transmit card decks to one another 


e Remote stations to send job streams to a CMS Batch virtual machine 
operating under the same VM/370 and have the output returned to the 
remote station 


e Remote stations to submit jobs or commands to any node in the network 
and direct the output to any node or remote station in the network. 
The default is return to origin. 


NPT is a line driver task operating under the control of the RSCS 
supervisor. Each NPT task drives one remote nonprogrammable station. 
In other words, each NPT task controls a single point-to-point 
communications line. The task is started by the RSCS operator, 
identified with a destination name, and provided with a leased or 
switched telephone line. The communications line is either identified 
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by the operator or derived from a table entry within RSCS. The line is 
then activated and the type of remote station and its configuration 
details are obtained from control cards entered at the remote station, 
or from a table entry within RSCS. After this initialization is done, 
the terminal may then be used to submit files via the card reader and 
receive files on the punch and printer. 


The remote station operator can control I/O activity via control cards 
and standard station procedures. The RSCS operator controls the 
operation with commands from his console. The virtual machine user 
retrieves files sent to his virtual machine by using normal virtual card 
reader management programs and directs output to the appropriate station 
using the SPOOL and TAG commands of VM/370. 


NPT operates with variations of the basic BSC protocol for each of the 
stations listed. The protocol is based upon the station identification 
information provided in a SIGNON card read at task initialization tine. 


PT Line Driver Send Function 


Check the status flags for the GETBLOCK processor: 


BUFEMPTY: is the unpack buffer (BUFUNPK) used to fill the line 
buffer (LINEBUFF) empty? 


HEADFLAG: is there a header record to be inserted into the line 
buffer? 


FILACTIV: is there a file being transmitted now or does one have to 
be obtained from WM/370? 


RDRCMD: are there any commands pending execution? 


EOF: has end-of-file been reached for the file currently being 
processed ? 


1. Get a Spool File Block to Transmit 
Branch to GETFILE. 


Test to see if there is a file to send. If there is a file, 
request AXS to open it for transmission. When the file is obtained 
determine whether it is a print or punch file, initialize data 
counters, buffers, and registers, and write message DMTNPT146I, 
indicating that a file is being sent. If there are errors, write 
appropriate messages, 


2. Write Header Record: HEADPREP 
If the header transmission flag is on, a printer header or 
printer/punch separator line is to be inserted into LINEBUFF via a 
branch to HEADPRERB 
HEADPREP tests for the type of file (print or punch) and inserts 
the appropriate line into the unpack buffer (BUFUNPK). On return 


from HEADPREP, the unpack buffer is packed for transmission on the 
BSC line. 


3. Process Spool File Block for transmission: MAKEBLOC 
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At GETLINE, if the BUFEMTPY flag is off, a new record is ready 
to be inserted into the line buffer. Check the maximum byte 
count and record count allowed in LINEBUFF and see if this 
record exceeds the maximum. If this record exceeds the 
maximum counts, the appropriate BSC control characters are 
inserted into LINEBUFF to complete the transmission sequence 
and control is passed back to the caller. 


If the record can be inserted in LINEBUFP, it is moved into 
LINEBOFF along with the appropriate BSC control characters. 
BUFEMTY is then turned on and a new record obtained via a 
branch to GETNEW. 


At VMSPOK, initialize counter registers and set FILLED flag on 
in GETFLAGS. If there is already a block to process an entry 
to MAKEBLOC, update the counter registers. 


At VMSPCCW, process the spool block record. Move the record 
into BUFUNPK. In the case of an immediate CCW command, only 
the CCW command is moved into BOFUNPK and IMDCMD flag is set 
on. 


At MAKERET, after the line has been converted for transmission 
a 0 is set as return code if there is more data to process. 

On end-of-file, a 4 is set as the return code. If there was 
an error during processing, message DMTNPTIS0E is written. 


a. Transmit Line: NPTGET 


ae 
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At NPTGET, check for messages and try to get a block of data 
to write from VWM/370. If there are no messages to process, 
branch to GETBLOCK to get a block of VM/370 data to transmit. 
On return from GETBLOCK with no data to transmit, determine 
whether there are files to read. 


At NPTSTART, on return from GETBLOCK with data to transmit, 
initialize the output buffer (LINEBUF) by: 


(1) Testing flags in the GETFLAGS table and Device Block, and 


(2) Moving into the Device Block the BSC control characters 
describing the features of the remote station to which a 
file is to be transmitted. 


Load the ENQPROG channel program into the Device Block and 
branch to LINEIO to execute an I/O operation requesting 
permission to transmit to the Remote Station. Test for the 
line errors resulting from the I/0 operation. 


At NPTENQOK, when the response to ENQ is correct, (DLE, ACKO) 
initialize control counters (constants and registers) for 
transmission of the file. EXREPLY contains the expected line 
error checking via BSC line protocol. DCX and INDEVSEL 
contain data control characters for printer and punch devices. 
Move the TALKPROG channel program into the Device Block. Set 
the return address to the GETVRFY routine. 


At NPTTALK, execute a write I/O operation by branching to the 
LINEIO routine. Set the return address to the GETVRFY 
routine. 


At NPTEOT, on end of file, move the EOTPROG channel program 
into the Device Block and branch to the LINEIO routine to send 
an end of transmission signal to the remote station. 
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Verify Response to Transmission: GETVRFY 


Check the response from the last transmission for: 


EXREPLY 
Either ACKO or ACK1, in the normal BSC transmission protocol. 


NAK 
Negative acknowledgement. 


EOT 

End of text - used to specify that the transmission is 
incomplete. Also, used to notify the receiving station that 
there are errors receiving data at this end of the line. 


ENQ 
Used to request permission to transmit a file. Also, used to 
"balance" the line in recovering from errors. 


When the EXRFPLY flag specifies that the expected reply has 
been received, the next expected reply is set (ACKO or ACK1) 
and control is returned to NPTGET. 


When a NAK is received, the NAK counter (STATNAK) is 
incremented a test is made to see if this is the second NAK by 
checking the NAKREC flag. If this is the first NAK received, 
retransmit the block by branching back to NPTGtT. If this is 
the second NAK, reset the line by sending an EOT and an ENQ. 


When an EOT response is received, try to send the block again. 


At REPENQ, when an ENQ is received, check for I/O errors, set 
ACK1 as the next response, and branch to NPTGET to continue 
processing. 


ENQ is sent to request permission to transmit or to resume 
transmission of a file after errors on the line or timeouts. 
After multiple ENQ transmission, send EOT to reset the line. 


6. Obtain each subsequent block of this file with DIAGNOSE x'14', 
subcode 0. 


Ts At GETPURGE, on end-of-file, write message DMTNPT1I47I, indicating 
that a file has been sent and purge the file via a branch to AXSs. 


PT Line 


TEST FOR 
BSC line 


[=] 
[ae] 
be 
ls 


Xr Receive Function 


nd 





REQUEST TO TRANSMIT FROM REMOTE STATION: At NPTGET, monitor the 
t 


1. Check for messages and try to get a block from VWM/370 to write. If 
there are no messages to process or VM/370 files to transmit, read 
from the BSC line to determine whether a file is being transmitted 
from a remote station. 


Ze At NPTINIT, read a line of data. 


Load the READPROG channel program into the device table describing 
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the I/O operation and branch to LINEIO to execute the read. If 
there were no flags set in the DEVFLAGS table, there is nothing 
being transmitted on the BSC line. In this case, branch back to 
NPTGET to try to get a V¥M/370 spool file to transmit. 


35 Test for request permission to transmit. 


When a line of data has been received over the BSC line, check the 
BSC control characters for a request to transmit. If such a 
request (ENQ) is not received, branch back to NPTDINIT to check for 
another operation to perfor, 


4. At NDTACKO, send permission to transmit. 


When an ENQ is received, load permission to transmit (ACK0) in the 
REPLY entry in the I/0 Counter Table, load the ACKPROG channel 
program in the Device Table for this I/0 operation and branch to 
LINEIO to transmit permission to transmit. On return from the I/0 
operation, check the results via a branch to PUTVRFY. 


VERIFY READ OPERATION BSC DATA: 





1. Check for I/O errors on the BSC lines PUTVRFY 


a. At PUTVRFY, check for I/0 errors during the last transmission. 
If there are no errors, processing continues at CKBUFF. 


b. At NPTNAK, if there are any errors, check for timeout. If a 
timeout error, send a NAK. If the maximum NAKs allowed are 
sent, reset the line by sending an EOT. If the maximum number 
of timeouts has occurred, close the file via a branch to 
PUTCLOSE in the PUTBLOCK routine. 


De Check the BSC control characters. 


ae At CKBUFF, check the BSC control characters of the buffer just 
received: STX or DLE STX for the leader and ETB or ETX at end 
of buffer. If all characters are acceptable, branch to 
PUTBLOCK to continue processing. 


b. At NPTTALK, if the leader characters are not STX or DLE STX, 
check for ENQ, EOT, or NAK. If an ENQ is received, send ACKO 
to the remote station. 


If an FOT or a NAK is received, set the FOTREC (EOT received) 
flag and branch to PUTBLOCK, 


Ce At REPLY2, if the leader characters are unidentifiable, load 
the "not ready" program, send it, and check for I/O errors and 
an ENQ. If the reply is not ENQ, send an ACKO back across the 
line. 


d. At NPTTALK1, if the reply is ENQ set the return address to 
PUTVRFY and go to LINEIO to write the next line. If there are 
I/O errors, exit to PUTCLOSE in the PUTBLOCK routine (REPLY3). 


RITE BLOCK OF DATA TO WM/370 SPOOL FILE: 








1. Check status of file processing. 
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At PUTBLOCK, determine the status of file processing by checking 
for an already active file, end of file, an error in processing, 
and setting the correct response to the received transmission ({ACK1 
or ACKO). If a file is active, continue processing. On end of 
file, close the file. If there was an error in processing, resend 
the buffer via a branch to NPTTALK1. 


Convert a line of data to VM/370 format. 


At TRT1, if a file is being processed, get the address of the line 
buffer and convert the characters to VM/370 format. When a biock 
is completely reformatted, get another via a branch to NPTTALK1. 


Determine whether the current record is a command. 


At FOUND, check the current record to see if it is a command. If 
the return code from the command processor is zero, branch to 
PUTSKIP to skip printing of the command line. 


Validate the userid of an ID card. 


In FOUND, check the current record to determine if it is an ID 
card. If the record is an ID card, validate the card and move the 
VM userid into TAGTOVM, the target virtual machine for the file to 
be processed. 


Open a file. 


At PUTOPEN, open the new file for processing by writing message 
DMTNPT144I, informing the operator that a file is being sent. 
Clear the request synchronization lock and request the supervisor 
GIVE request routine to handle the open request. On return from 
the GIVE processor, set the FILEOPEN flag and get the first block 
of data via a branch to NPTTALK1 (via PUTSKIP, where printing of 
the ID card is skipped). 


Write a block of data to a ¥M/370 spool file. 


ae At PUTWRITE, write a block of data to a VM/370 spool file by 
decompressing the record, if required, loading the PUTPROG 
channel program, and branching to LINEIO to handle the I/0 
operation. 


b. At PUTSKIP, records that need not be written to the file (such 
as commands, ID cards, and blank records) are skipped. 


When a write operation is interrupted by EOT or an alert, 
processing is continued via a branch to PUTCLS4. 


Close a file. 


At PUTCLOSE, close the file by writing message DMTNPT145I, 
informing the operator that a file has been received, clearing the 
synchronization lock, setting the close function code in the 
request block, and requesting the MSUP Supervisor GIVE request 
handler to close the file. If the file is not open, issue message 
DMTNPT934E. 
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VMB LINE DRIVER FUNCTION DESCRIPTION 


The VMB line driver (DMTVMB) is for transmitting VM/370 spool files 
between VM/370 systems over BSC lines. DMTVMB communicates with another 
copy of itself using the file address specified on the VM/370 TAG 
command (location and userid) to determine the recipient virtual 
machine. DMTVMB supports both print and punch file transmission between 
users operating on two different VM/370 machines or transmission from a 
vM/370 user to a real unit record device on a remote VM/370 machine. 


The VMB Line Driver employs a variation of standard BSC protocol similar 
to MULTI-LEAVING; it is transparent, symmetrical, and can sustain 
simultaneous two-way data transfer by interleaving block reception and 
transmission. All data records are compacted by reducing all sequences 
of five or more identical characters into a four-character sequence. 
Standard BSC transparency mode is used for data transmission to remove 
restrictions on data content. The protocol is symmetrical, with no 
master/slave relationship between the communicating systems. 


WMB BSC Telecommunication Protocol 


VMB protocol provides a quiesced state when neither system has data to 
transmit to the other. This provision avoids forcing the CPU cluster to 
an active state (thereby running the system meter) when communication is 
available but not actually active. Communication may be restarted by 
either of the connected systems when data arrives for transmission. 
Contention (simultaneous activation) is not a problem, because data flow 
can commence in both directions as soon as transmission exchange is 
synchronized. 


Bidirectional interleaved half-duplex communication is achieved through 
the use of the block header for acknowledgment or rejection of the 
previously received transmission. The acknowledgment byte flag setting 
in the block header explicitly confirms successful reception and 
processing of the data transmitted by the remote system in the preceding 
line sequence. When a received block cannot be processed because system 
resources have been exhausted, an acknowledgment byte flag setting 
requests retransmission of the block. 


If recoverable I/O errors occur during a block transmission, the 
receiver responds with a negative acknowledgment (NAK), requesting 
complete retransmission of the preceding sequence. Serious line I/0 
errors, negative acknowledgments to negative acknowledgments and long 
duration timeouts (>15 seconds) while waiting for response are condi- 
tions that terminate exchange synchronization. Exchange may then be 
restarted as from the quiesced state by either system with data to 
transmit. 


w 


BSC Iransmission Sequences 
BSC TRANSMISSION SEQUENCE WITHOUT DATA 
AS TRANSMITTED --> 

SYN, SYN, SYN, SYN, SOH, 00, 00, 00, 00, [( 1) J], ETB 
AS RECEIVED --> 


SOH, 00, 00, 00, 00, [( 1)], ETB, (2) 
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AS TRANSMITTED -—-> 
SYN, SYN, SYN, SYN, SOH, 00, 00, 00, 00, [( 1) ], ITB, SYN, SYN, 
ty', 'mt) tet, tat, (3), (4 - FIVE BYTES), ( 5 - TWO BYTES), 
DLE, STX, ( 6 - PACKED DATA), DLE, ETB 

AS RECEIVED --> 
SOH, 00, 00, 00, 00, [(1) ], ITB, (2), 
‘vt, tH, *Rt, tat, (3), ( 4 - FIVE FYTES), ( 5 - TWO BYTES), 
DLE, STX, ( 6 - PACKED DATA), DLE, ETB, (2 ) 


Explanation of Underlined Digits in Above Sequences 





41 Acknowledgment flag, present only when the preceding transmission 
from the remote station included a packed data block. 

X'80' - Preceding block was successfully received and processed, 
and may be discarded by the sender. 

X'AO' ~ Preceding block was successfully received, but could not be 
processed due to lack of available system resources - 
transmission must be retried later. 

2 An error index byte that is generated by the BSC telecommunications 
adapter operating in "ITB Mode", to flag data errors detected by 
check sum mismatches. 

3 A one-byte EBCDIC block sequence number, modulo 8 (X'FO'-X'F7'), 
used to detect possible duplicated transmissions so that the 
duplicated data may be discarded. 

4 A five-byte EBCDIC data block content descriptor: 

C'SYNCH' - Null data block - intended to be discarded. (This is 
used on line driver restart so that the initial data 
transmission will not be erroneously discarded due toa 
spurious block serial number match.) \ 

C*PRINT* -— Print image data. 

C*PUNCH' - Card image data. 

C'mMSGHD' - Commands, messages, or link control records. 

5 A two-byte formatted packed data count: 

11 xX x x xX x xX X¥f{141 X X¥ X¥ X¥ X X Xf 
bot t tf §€ t € § FF § € tt t YT FI 
{ High-Order Count Bits | Low-Order Count Bits | 
The packed data count is constructed by discarding the high-order 
bit of each of the two count bytes and juxtaposing the remaining 
bits into a 14-bit binary count. (The high-order bit of each byte 
is always set to "1" to avoid possible duplication of a BSC control 
character, because only the packed data block itself is transmitted 
in transparency mode.) 

6 One or more packed data records, to a maximum length of 824 bytes. 


Figure 2-21 shows the protocol for transmission error retry and Figure 
2-22 shows typical line transactions. | 
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TERMINUS 1 TERMINUS 2 
* TIME * 
* | * 
* | * 
{ 
{ V I 
{ I 
{ ee | 
----> | BLOCK 1 | ~---> RECEIVES BLOCK O.K. 
{ —_______—_—J I 
| | 
DETECTS I ——-——"1 | 
ERROR <---- | BLOCK 2 I <---- 
I t—__________-J | 
{ { 
—---> 'NAK® ~---> RECEIVES 'NAK! 
{ —_— | 
RECEIVES <---- | BLOCK 2 | <---- RESENDS LAST RLOCK 
BLOCK O.K. | tS | 
| co eer} | 
----> | BLOCK 3 | ----> 
| aed | 
t | 
I I 
* * 
* * 
* * 


Figure 2-21. Protocol for Transmission Error Retry 
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Figure 2-22. Typical Line Transactions 
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Format 








DMTVMB Packed Data Bloc 


DMTVMB scans the output data and builds packed formatted blocks which 
are actually transmitted on the telecommunications lines. The data are 
packed by compressing all occurrences of five or more identical 
characters in a record into a coded field which adds only four bytes to 
the packed record. When the data blocks are received by the remote RSCS 
system, the records are correspondingly unpacked by DMTVMB before being 
entered as output in the ¥M/370 spool system. 


Transmission data blocks are of variable length, depending on content, 
up to a maximum length of 824 bytes. Each block contains a variable 
integral number of packed records of variable length, each of which 
corresponds to a single unpacked record. There are no partial records 
in a block; if a packed record will not fit at the end of a block 
without extending the block beyond the 824-byte limit, the block is 
terminated and the record is placed at the start of the next block. 


The packed data record format is: 


Lo tok ee 
A. | CM | DL | DATA << { 





1d Dee eet 
+0 +1 +2 +N 
Where: 
CM ~~ a Systen/370 Channel Command Word (CCW) command code used to 
output the record by the originating virtual machine. 
DL -- number of bytes (in hexadecimal) in the packed DATA field. 
DATA -- data comprising a single record in mixed packed and segment 


format as shown below. 


The DATA field format is: 











| I >> I | | ! | > > 1 
{| SL | SEG. < < DATA | FF | CH [| RF {| SL J ..< <.. | 
I Aste ee a ee I | eee, |e ee eee | 
+2 +3 +M M41 +M4+2 M43 +M44 +N 
Where: 
SL -- a one-byte hexadecimal count equal to one less 


than the length of the segment data, SEG. DATA. 


SEG. -- a string of data to appear unmodified in the 
DATA unpacked record. 


FF -- a flag (X'FF') which indicates the start of a 
packed segment. 


CH -~- a data character to be replicated a number of 
times in the unpacked record. 


RF -- a hexadecimal count equal to two less than the 


the total number of characters, all "CH", to 
appear in the unpacked record. 


86 IBM VM/370: RSCS Networking Logic 


Licensed Material - Property of IBM 








I | 
B. | CM j DL | 
{___| { 
+0 +1 +2 
Where: 
CM -- a Systen/370 immediate (non-data moving) control command 
code, for a print or punch output device. 
DL -- a data count of X'00', which implies that the CM command is 
of the immediate control type. 
if 
Cc. | FL I 
| eee 
+0 +1 
Where: 
FL -- a flag byte which has one of the two following values: 
X'FF' -- end of data block; more data blocks exist 
for the file. 
X'EF' -- end of data block and end of file; no more 
data blocks exist for the file. 
YMB Line Handling 
A. VMRENABLE - This routine is entered after VMB initialization has 


completed, and each time the telecommunication line drops 
(signalling “intervention required") during VMB processing. It 
issues message DMNTVMB141I to notify the operator that the line 
should be connected in case manual intervention is required (such 
as when a dialable port is in use), and starts execution of the 


line enabling sequence. 


This enabling sequence comprises three command chained CCW's: 
DISABLE, SET MODE, and ENABLE. 


The DISABLE command disconnects any previous dial port connection, 
and places the telecommunication adapter in the disabled state. 


The SET MODE command places the telecommunication adapter in ITB 
mode, such that on subsequent read operations an incoming ITB BSC 
control character will be recognized, the following two BCC 
characters will be interpreted, and an EIB character reflecting 
presence or absence of errors will be entered into the read buffer. 


The ENABLE command completes, placing the telecommunication adapter 
in the enabled state, when the port's modem signals "data set 
ready". For a dialable port, this occurs when the dial connection 
completes; and for a leased line, "data set ready" is signalled 
whenever the line and modem equipment are functional. 


When this enabling sequence completes, control is passed to 


VMRSTART to verify link identifiers and passwords, and normal 
processing begins. 
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VMRGET - This routine is entered when VMB is in the quiesced 
communication state, and data may be available for transmission to 
the remote system. The hold and drain statuses are checked, and a 
call is made to GETBLOCK to prepare a data block for transmsission. 
If communication is allowed and a data block is ready, control is 
passed to VMRSTART to initiate the exchange. Otherwise, the read 
initial sequence (command chained PREPARE and READ commands) is 
started, and communication remains quiesced. 


The PREPARE command completes only when halted by the AXSALERT 
routine, or when the remote system initiates a transmission. In 
the former case, VMRGET is reentered from the beginning. In the 
latter case, a DLE-ACKO sequence is written to the remote systen; 
if signon has already occurred, control is passed to VMRVERFY (in 
the VMRGO routine) to begin processing incoming data. Otherwise, 
signon blocks are exchanged and verified before any data transfer 
is allowed to occur. 


VMRSTART - This routine is entered upon successful completion of 
the line enabling process, and each time communication is to be 
reactivated from a quiesced state. The block exchange channel 
program is initialized, and an attempt is made to exchange the 
initial ENQ, DLE-ACKO, and signon sequences. When successful, 
control is passed to VMRCHARG (in the VMRGO routine) to initiate 
data exchange. If no response is received from the remote system 
for the duration of the ENQ retry sequence, control is passed to 
VMRDINIT (in the VMRGET routine) and communication remains 
quiescent. 


VMRGO - This routine comprises the central control logic for normal 
VMB transmission-reception activity. At VMRGO, a transmission has 
been received from the remote system. If a NAK has been received, 
the preceding transmission is repeated. Otherwise, the received 
sequence is checked for validity, and a NAK is transmitted (at 
VMRNAK) if it is invalid. If a signon block is received, it is 
verified by a call to PASSCHEK, and a signon block is returned by a 
call to PASSSEND. If a data block is received, it is processed by 
a call to PUTBLOCK. The GETBLOCK routine is called to prepare a 
data block for transmission to the remote system, if any such data 
is available. If no data block is available for transmission, and 
no data block was received on the last transmission from the remote 
system, an EOT is transmitted at VMREOT and control is passed to 
VMRGET to quiesce communication. 


The main telecommunication channel program is executed at label 
VMRTALK. This channel program comprises several data chained write 
CCWs, command chained to a read CCW. It is built mainly by 
GETBLOCK, and its structure can include TICs, depending upon the 
presence of an acknowledgement byte and data block in the 
transmission to be made. When the exchange is successful, the 
transmission will have been written to the remote system, the 
response will have been read into the line input buffer (LINEBUFF), 
and control is passed back to VMRGO for another exchange cycle. 


LINEIO - This routine is called to perform all I/O operations on 
the telecommunication port. The I/O request is executed as set in 
the line I/O table (LINE) by a call to XECUTE, and call is made to 
KLOGIT to log the results. If the I/O is successful, return is 
immediately made to the caller. If a serious error occurs, control 
is passed to VMRBADIO, which issues an error message and 
deactivates the line driver. When contention is detected, a read 
is executed, an error is flagged, and control is returned to the 
caller. If “intervention required" is detected, message 143 is 
issued and control is passed to VMRGET if no response is read. If 
an error is detected that can be corrected on retry, an error is 
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flagged, and control is returned to the caller. 


TRTRAN, TRERR, TRIIMOT - The trace sum routines are called by the 
various line management routines to count the accumulated number of 
successful transmissions, line errors, and timeouts, respectively. 
These counts are constantly maintained in the line driver's link 
table, where they may be interrogated by an RSCS operator "QUERY 
linkid SUM" command. When sum tracing is active, message 149 is 
issued each time any of the counts reaches a threshold value, and 
all counts are reset to zero. 


KLOGIT - This routine is entered after every line I/0 transaction. 
When log trace is set on by a "TRACE linkid LOG" command a print 
output file is opened by a call to AXS, and each subsequent I/0 
execution is formatted and recorded in the print file. The print 
file is scheduled for printer processing when the file is closed by 
a call to AXS from the command processor on execution of a "TRACE 
linkid NOLOG" command. 








GETBLOCK - This routine is called by the line management routines 
to prepare data blocks for transmission to the remote system. The 
data blocks may be initial null pad (SYNCH) blocks, CMD/MSG element 
(MSGHD) blocks, or spool data blocks. 


Upon entry, control is passed to GETPAD if the block to be 
constructed is the first to be transmitted following initialization 
or line connection. In this case, a null data block is constructed 
with a SYNCH header, and control is passed to GETSETUP. 


If no SYNCH block is to be generated, a call is made to MSGTRANS if 
at least one CMD or MSG element is queued for transmission. When 
the MSGHD block has been built by MSGTRANS, control is passed to 
GETSETUP. 


If none of the above conditions exist, an attempt is made to build 
a spool data block. If no input spool file is open, control is 

passed to GETFILE. Otherwise, a call is made to MAKEBLOK to build 
a spool data block. If an end-of-file condition on the input spool 
file is encountered, message DMTVMB147I is issued, the old file is 
purged, and control is passed to GETFILE. When a spool data block 
is successfully built by MAKEBLOK, control is passed to GETGOT. 


At GETFILE, the drain and hold request status are tested. If drain 
is set, no block is built and control is returned to the caller. 

If hold is requested, message DMTVMB611I is issued, the link is 
placed in hold status, and control is returned to the caller with 
no block built. If an input spool file is potentially available, a 
call is made to AXSGET to attempt to open an input file. If 
successful, control is passed to GETGOT; otherwise, control is 
returned to the caller with no block built. 


At GETGOT, a spool data block has been built and is ready for 
transmission in GFTBUFF. Pending commands are tested for validity 
and applicability, and rejected with diagnostic messages if 
invalid. Valid pending commands are executed with confirmation 
messages. If a new file has been opened, messages DMTVMB146I or 
DMTVMB148I are issued, as appropriate, and control is passed to 
GETSETUP. 


At GETSETUP, the generated block length is determined and is stored 
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in the block write CCW (WRITDATA) and in the block header. The 
block serial number is generated and stored in the block header, 
and control is returned to the calling line management routine. 


PUTBLOCK - This routine is called by the line management routines 
to process data blocks received from the remote system. Data 
blocks with serial numbers matching the previously-received serial 
number are discarded. 


The received data block is processed by decompressing each record 
at PUTNEXT, and passing control to PUTOUT for individual record 
processing. When processing has been completed for a record, 
control is returned to PUTNEXT, which decompresses the next record 
in the block and passes control to PUTOUT. When no records remain 
in the block, control is passed to PUTDONE, which checks for 
end-of-file on spool data output. If end-of-file is detected, 
message DMTVMB145I is issued, the file is closed by a request to 
AXS, and all output file status is reset. Finally, control is 
returned to the calling line management routine. 


At PUTOUT, the record to be processed is tested to determine if it 
is a link command element or a CMD/MSG element. For a RESTART link 
command element, a flag is set to cause GETBLOCK to restart its 
active input spool file from the beginning when such a file is 
present, and the next record is processed. For a PURGE link 
command element, the active output file (if any) is closed and 
purged by a call to AXS. For a TAGB control record, the active 
output spool file (if any) is closed and purged by a request to 
AXS, the new output tag status is updated and reset according to 
the contents of the tag record, and the next record is processed. 
For a CMD or MSG element, MSGRECV is called to pass the element to 
REX for further processing, and the next record is processed. All 
other records are interpreted as spool output records, and control 
is passed to PUTOPEN. 


At PUTOPEN, an output spool file is opened by a request to AXS and 
message DMTVMB144I is issued if no output file was already open and 
if the link is not in drain status. If the link is in drain status 
and an input file is still being processed, a WABT response is set 
for transmission to the remote system. If the link is in drain 
status and no other file is being processed, control is passed to 
VMREOT to terminate communication and line driver processing. 
Control is passed to PUTWRITE when a spool output file is open. 


At PUTWRITE, the decompressed record is written into the output 
spool file using the CCW command code supplied with the record. 

NOP records (command code X'03') are executed as normal writes, 
because they may represent transparent control information which is 
to be embedded in the spool file and preserved. If the write 
operation is successful, the next record is processed. Otherwise, 
a diagnostic message is issued and line driver processing is 
terminated by a call to VMRTILT. 


MSGRECV - This routine is called by PUTBLOCK to process CMD and MSG 
elements as they are received. Each such record is given to REX as 
a request. REX, in turn, executes commands and issues messages 
contained in elements addressed to the local location, and forwards 
other elements to line drivers for transmission to remote systems. 
When the request has been accepted by REX, control is returned to 
the caller. 


MSG - This routine is called throughout VMB, normally from within 
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E. 


s 8) ro, to format and issue message 
requests to REX. On each call, a message request element is built 
using the message number and substitution parameters supplied by 
the caller. The request element is passed to REX, which builds and 
distributes the requested message. When REX has completed 
processing the request, control is returned to the caller. 


AXSGET - This routine is called by GETBLOCK to prepare an input 
spool file for reading and transmission, It starts by issuing an 
OPEN INPUT request to AXS. If no input spool file is available, 
AXS returns an error indication and control is immediately returned 
to the caller, reflecting the error. If a file is successfully 
opened, the new input file status is set, a transmission block is 
built by a call to MAKEBLOK, and control is returned to the caller 
indicating successful completion. 


AXSPURGE - This routine is called by GETBLOCK to teiminate 
processing of an active input spool file. The file may be deleted 
or saved (reenqueued) for future processing, depending on the 
request set by the caller. A CLOSE request is built and passed to 
AXS for execution. When complete, VMB's active input spool file 
status is reset, and control is returned to the caller. 


MSGTRANS - This routine is called by the line management routines 
to build a data block, containing CMD and MSG elements, for 
transmission. GMSGREQ in DMTCOM is called repeatedly to dequeue 
and retrieve elements stacked by AXSALERT. Each record retrieved 
is formatted into a NOP data record, compressed by a call to PACK, 
and entered into the data block buffer (GETBUFF). When no more 
elements are available, or when the 824-byte data block length 
limit is reached, the block is terminated, and is returned to the 
caller with a MSGHD header code. When no elements are available, 
an error indication is returned to the caller. 


MAKEBLOK - This routine is called by the iine management routine to 
build a data block, containing spool data records, for 
transmission. Page buffer spool data blocks are read from the open 
input spool file by a hypervisor call (DIAGNOSE X'14', subcode 0) 
to CP. Each spool page buffer is decomposed record by record. 

Each record is compressed by a call to PACK, and entered into the 
data block buffer (GETBUFF). When a data block has reached the 
824-byte length limit, or when the spool data input has been 
exhausted, the block is terminated and control is returned to the 
caller. When input data records remain on completion of data block 
construction, the records and deblocking pointers are saved. The 
next call to MAKEBLOK resumes with the next sequential record. 


PACK - This routine is called by MSGTRANS and MAKEBLOK to compress 
a line of data into the VMB packed data format (see DMTVMB Packed 
Data Block Format). A single line of data is accepted as input, 
along with its character count. The line is searched for sequences 
of five or more identical characters by a compare logical character 
instruction specifying overlapping one-byte offset fields, each 
four characters long. When such a sequence is located, the 
previous segment data string (if any) is entered into the caller's 
output buffer, and the packed sequence is entered with its length 
and replicated data character. If more input characters remain, 
the search for identical characters and the construction of the 
output string continues as described above. When the end of the 
input string is reached, the output buffer is completed with the 
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final data segment or packed sequence, the packed output string 
count is stored in the first byte of the output buffer, and control 
is returned to the caller. 


——— ee eee ee om 


SVMRINIT - This routine is executed only when a VMB line driver is 
initially started. The start parameter string is inspected for 
validity, and, if valid, the link passwords are set as specified. 
Otherwise, a diagnostic message is issued and the passwords are 
left unspecified. The link table address, the device address of 
the line in use, and the link ID are located and saved for future 
use. The prototype tag blocks to be used in OPEN OUTPUT requests 
to AXS are initialized to their default values. ASYNREQ in MSUP is 
called to specify AXSALERT as the line driver task's entry point 
for alert calls from other tasks (REY alerts line drivers for 
command and CMD/MSG element transfer, and AXS alerts line drivers 
for notification of file availability). A RESTART link command 
element is stacked for transmission to the remote system, to cause 
the remote system to terminate active output file processing and 
restart active input file processing. Finally, a flag is set to 
force transmission of an initial pad (SYNCH) block, SVMRINIT's 
storage page is released, and processing is begun at VMRENABL. 


CMDPROC - This routine is called by XECUTE when a wait request 
completes with the posting of the command arrival synchronization 
lock (CMDECB), following the acceptance of a command alert element 
from REX. The command code table (CMDTABLE) is searched for a code 
matching that of the accepted element, and the command's processing 
routine is entered when a match is made. If no match is found, the 
command is ignored. The command processing routines are: 


Ce an I gt TRG RIS, ES PON a a a eee ee 
| ROUTINE | COMMAND IT PROCESSES | 
{$f} —_______--_____+ 


SETSTART START command 
SETDRAIN DRAIN command 
SETFPREE FREE conmand 


SETTRACE TRACE command 
SETBACK BACKSPAC command 
SETFWD FWDS PACE command 
SETFLUSH FLUSH command 


| 
I 
| 
SETHOLD | HOLD command 
| 
| 
{ 
| 


rene ey ee Oe 


These individual command processors normally issue messages, set 
flags, and modify other line driver status, depending upon the 
particular command and the processing status of the line driver. 
In addition, the SETTRACE routine requests open and close spool 
output from AXS for line activity log initiation and termination. 
When processing is complete, control is returned to the caller. 


AXSALERT ~ This rcutine is entered asynchronously in masked-off 
Supervisor state from the MSUP ALERT processor (DMTSIG) on an alert 
call from another task. If the alerting task is AXS, the call isa 
notification that an input file has become available for the line 
driver's link. In this case, "file available" status is set, line 
I/O is terminated by an HDV command when read initial (PREPARE 
command) is active, and control is returned to MSUP. 
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VB 


A. 


If the alerting task is REX, the e 
inspected. For CMD and MSG elements, control is passed to AXSMENQ 
which calls PMSGREQ in DMTCOM to stack the element for future 
transmission to the remote system. Otherwise, REX is assumed to be 
presenting an operator command element. If an operator command is 
already in progress, the request is rejected and an error 
indication is returned to REX via MSUP on return. If no command is 
already in progress, the command element is moved to VMB's command 
element buffer (CMDRESP), the line I/0 is halted if read initial 
(PREPARE command) is active, the active command presence is 
flagged, and control is returned to MSUP with a normal completion 
code for REX. 


lement code heinad nresantead is 
semen c 
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If the alerting task is other than AXS or REX (which should not 
happen), the alert call is ignored and control is returned to MSUP. 


D. VMRTILT - This routine is entered from various locations in 
V4B, and its function is to terminate iine driver processing. 
If the reason for termination is a fatal I/O error, entry is 
made at VMRBADIO. In this case, IOERRPRT is called to issue a 
diagnostic I/O error and the device in error is marked 
"inoperative" before termination processing. 


At VMRTILT, line I/O logging is terminated if active, and any 
active line I/0 is halted by an HDV instruction. If the line 
port remains operative, a DISABLE operation is executed to 
reset the port and disconnect (hang up) dialable telephone 
data sets. Finally, a task termination request is issued to 
REX, and VMB enters a permanent wait state until it is deleted 
from the system as a result of a call to MSUP, which is made 
by REX during its processing of the terminate request. 


I/O Management Functions 





XECUTE - This routine is called throughout VMB to execute I/0 
channel programs for all I/O devices. The I/0 table is prepared 
for execution by the caller, including the address of the channel 
program and the device on which it is to be executed, and the 
address of the I/O table is passed to XECUTE in register 13. 


XECUTE begins by clearing the synchronization lock in the caller's 
I/O table and calling IOREQ in MSUP, specifying the I/0 table, to 
schedule and execute the requested I/0. The address of the I/0 
table synchronization lock is stored in a wait list that also 
includes the command arrival synchronization lock, and WAITREQ in 
MSUP is called to suspend line driver task dispatching until the 
I/O completes, or until a command alert element is delivered. When 
a command alert element arrives, it is processed by a call to 
CMDPROC, and the wait request is repeated if the I/O request has 
not completed. When the I/O manager in MSUP signals completion by 
posting the synchronization lock in the I/0 table, control is 
returned to the caller. 


IOERRPRT - This routine is called from throughout VMB whenever the 
standard I/0 error message 70 is to be issued. The caller passes 
the address of the I/0 table containing the ending I/0 error 
information to IOERRPRT in register 13. The device address, ending 
CSW, SIO condition code, and ending CCW are extracted from the 
caller's I/0 table, converted to EBCDIC, and placed in the message 
request element. The message routing code is set to the VM/370 and 
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RSCS operator consoles, the MSG routine is called to issue the 
message request, and control is returned to the caller. 


VMC LINE DRIVER FUNCTION DESCRIPTIONS 


The VMC line driver (DMTVMC) is for transmitting VM/370 spool files 
between VM/370 systems over channel-to-channel adapters (CTCAS). DMTVMC 
passes VM/370 4K spool page buffers to another copy of itself, using a 
specially designed protocol to optimize utilization of the CTCA without 
creating heavy I/O activity. The 4K block is read from the WM/370 spool 
system, transmitted across the CTCA, and then written into the receiving 
machine's spool system with minimal SIO execution. Like DMTVMB, DMTVMC 
requires no special operating instructions, and supports the full RSCS 
command language except for BACKSPAC, HOLD IMMED, and FWDSPACE count. 


ICG 


Main Line Driver Control 





This routine is responsible for the main DMTVMC line driver control of 
the channel-to-channel adapter (CTCA). CTCGO is entered from CTCINIT 
after line driver initialization is complete. A wait is issued on a 
list of four synch locks until there is work to be done. The synch 
locks are: 


1. RDYRDY - This synch lock is posted by the asynchronous exit 
AXSALERT in DATVMC whenever an alert notification is given from the 
AXS task indicating than an input file is ready to be transmitted. 


2e MSGECB - This synch lock is posted by the asynchronous exit 
AXSALERT in DMTVMC whenever a command or message to be transmitted 
across the CTCA has been entered into the link's message stack. 


33 CMDECB - This synch lock is posted by the asynchronous.exit 
AXSALERT in DMTVMC whenever a command to be executed by the line 
driver locally is placed in the CMDRESP buffer after an alert from 
DMTCMX. 


4. ATTNLOCK - This synch lock is posted by the asynchronous exit 
CTCATTN whenever an attention interrupt is received on the CTCA. 
This indicates that the other side of the CICA is requesting that 
communications be established. 


When one or more of these synch locks is posted, I/0 activity on the 
CTCA is initiated to transmit or receive data. Calls are made to 
MSGTRANS and GETBLOCK to block data for transmission and to MSGRECV and 
PUTBLOCK to process received data blocks. When there is no more work to 
do, a wait on the synch lock list is again issued. 


Calls are made to LINEIO to initiate an I/0 operation on the CTCA. When 
an I/O request for a read or a write is made to DMTIOM, a timer request 
is made to DMTREX to post the TIMELOCK synch lock 15 seconds later. A 
wait is then issued on both the device synch lock and the time synch 
lock. If the other end does not complete the I/O operation before the 
time interval of 15 seconds expires, the I/O operation is terminated 
through an HDV instruction to the CTCA. This operation is done to 
prevent the read/write operation from inhibiting read channel activity 
if the remote system has gone down. 
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3ETBLOCK 





This routine is entered from the main processing routine in DMTVMC 
(CTCGO) whenever the File Available synch lock is posted, or after an 
input file has been processed. A call is made, if required, to AXSGET 
to obtain a new spool file to be transmitted. If a new file is not 
obtained, return is made to CTCGO. If a new file is obtained, message 
DMTVMC146I is issued, and return is made to CTCGO with a full block 
indicated. Successive calls to GETBLOCK will return 4K spool page 
buffers to be transmitted until an end of file condition. When 
end-of-file occurs on the input spool device, an end-of-file record is 
returned to be transmitted, to close the output spool file on the 
receiving systen. 


Cu 


GRECV = Command or Message Receipt 


MSGRECV 


This routine is entered from CTCGO when a block that contains a command 
or message is received. This record is converted into a routing request 
element and passed through GIVE/TAKE to DMTRGX for processing. 


MSGTRANS 


Command or Message Transmittal 





This routine is entered from CTCGO when the MSGQUED flag and the MSGECB 
synch lock have been posted by the asynchronous exit, AXSALERT. The 
message or command is placed in a message transmission buffer for 
transmission across the CTCA. The MSGQUED flag is not reset, indicating 
that there are more messages or commands to be transmitted. When a 
non-zero return code is obtained from the call to GMSGREG, the MSGQUED 
flag is reset and control is returned to CTCGO. 


PUTBLOCK 


This routine is entered by CICGO whenever a spool data block is received 
across the CTCA. When a tag record is encountered, a new spool output 
device is obtained via a GIVE/TAKE call to DMTAXS. If a file was 
previously open, a restart is assumed, and the file is closed and 
purged. If the file being received is destined for the local location, 
a header line indicating the file origin is placed in the output spool 
file. Each successive data block has the format of a VWM/370 4K spool 
page buffer. This buffer is relocated in the same manner as performed 
by module DMKRSP in CP. Once the data has been relocated, one virtual 
SIO is issued to write the entire buffer into the VM/370 spool systen. 
When an end-of-file record is received, the output spool file is closed 
via a GIVE/TAKE call to DMTAXS. 


CMDPROC 


(See CMDPROC under VMB Processing Control Functions.) 


Section 2: Method of Operation - Line Driver Functions 95 


Licensed Material - Property of IBM 


AXSALERT 


(See AXSALERT under VMB Processing Control Functions.) 


The trace sum routines are called by the various line management 
routines to count the accumulated number of successful transmissions, 
line errors, and timeouts, respectively. These counts are constantly 
maintained in the line driver's link table, where they may be interro- 
gated by a "QUERY linkid SUM" command. When sum tracing is active, 
message DMTxxx149I is issued each time any of the counts reaches a 
threshold value, and all counts are reset to zero. 


KLOGIT 


This routine is entered after every line I/O transaction. When log 
trace is set on by a "TRACE linkid LOG" command, a print output file is 
opened by a call to AXS, and each subsequent I/0 execution is formatted 
and recorded in the print file. The print file is scheduled for printer 
processing when the file is closed by a call to AXS from the command 
processor on execution of a "TRACE linkid NOLOG" command. 


NJI LINE DRIVER FUNCTION DESCRIPTIONS 


The NJI line driver (DMTNJI) communicates with non VM/370 NJI or NJE 
systems. The line driver consists of three preloaded modules (see 
Preiloader, Appendix B): 


DMTNCM - acts as main control of DMTNJI, manages the communications 
adapter and interfaces to the VM/370 spool system through the 
DMTAXS task. 


DMTNHD - processes NJI/NJE header records for jobs, output, commands, 


anA ma 
Use no 


yoo e 

DMINIT - handles line driver initialization. This module verifies 
parameters, obtains storage for teleprocessing buffers and unit 
record tanks, and constructs the initial SIGNON record. The 
storage for this module is freed upon return to DMTNCM. 


DATNJI conforms to the protocol defined by the Network Job Entry 
facility for JES2. This protocol is an extension to the remote job 
entry protocol used by the DMTSML line driver. 


This protocol extends the definition of MULTI-LEAVING for symmetrical 
communication between host systems. For moré information, refer to 
Appendix A. The data flow diagram for DMTSML is extended for DM#TNJI 
(Figure 2-23). 


The NJI line driver supports communication over bsc lines with 
MULTI-LEAVING and over channel-to-channel adapters. 
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Figure 2-23. NJI Link Data Flow 


The DMTNCM module comprises the following basic routines: 


e A function selector that dispatches one of the processors or other 
routines in NCM when a request for services is received. 


e Processors, that execute the main functions required by the network 
inter face. 


e An input/output routine that accepts and transmits data on the 
communication adapter. 


e Buffer blocking and deblocking routines. 


NCM Function Selector Routine: $START 


——— See eee eee 





The $START routine is entered when NCM is required (by either a remote 
system or a virtual machine) to perform a function. This routine 
selects a function to execute by using a commutator table, a list of 
synch locks, and task control tables. 


The NCM commutator table is a branch table consisting of unconditional 
branch and no-operation instructions. The targets of the branch 
instructions are the seven processor routines, the I/O handling routine, 
and the buffer handling routines. When the service of a routine is not 
required, the commutator table entry for that routine is made a NOP 
instruction. When the function of the routine is required, the NOP 
instruction in the commutator table entry for that routine is replaced 
with an unconditional Branch instruction, thereby opening a gate in the 
commutator table. 


The $START routine cycles through the commutator table, falling through 
any NOP instructions and taking any branches. Control is passed in this 
way to any routine whose gate in the commutator table is open. 


When the routine completes the function requested, it closes that 
function's gate in the commutator table by replacing the unconditional 
branch instruction with a NOP instruction. $START continues cycling 
through the commutator table taking any open branches. 


When the bottom of the commutator table is reached, $START tests a 
series of synch locks to see if any have been posted, signifying a 
request for an NCM function. If any synch lock is posted, $START opens 
the commutator table gate for the requested processor and goes to the 
top of the commutator table to start cycling through it again. 
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If the bottom of the commutator table is reached and there are no posted 
synch locks, NCM discontinues processing by issuing a wait request via a 
call to the supervisor module DMTWAT, waiting on a list of the synch 
locks. When any of the synch locks is posted, $START receives control, 
opens the appropriate gate, and starts cycling through the commutator 
table. 


NCM Processors 


Each processor performs a specific function necessary for network job 
entry. Figure 2-24 summarizes the processors in DMTNCM. 


Each processor has a task control table (TCT) associated with it that 
defines data required by the processor. Within the TCT is a branch 
instruction to the appropriate processor. The commutator addresses 
these TCT branch instructions instead of branching directly to the 
processors. 


Sa, ag A a aE a | 
{| PROCESSOR | FUNC TION 1 


{ Processes the following MULTI-LFEAVING control records: [ 
{ Permission To Transmit | 
{ Request To Transmit ! 
| Negative Open | 
| Signon Control Records | 


{ SPRIN1 { Processes output files from a remote system. Interfaces | 
| | with DMTNHD to process network header records. { 
| $URTN1 { Processes job files from a remote system. Interfaces | 
{ | with DMTNHD to process network header records. | 
{| SWRIN1 | Processes commands and messages from a remote systen. | 
| { Interfaces with DMTNHD to process network header records. | 
(-——_--—___+- tT 
| $RRTN1 {| Prepares records read from the VM/370 spool system for | 


| { transmission. Interfaces with DMNTNHD to build network | 
| | header records. i 
-———-———_ + -—- 
| CMDPROC | Executes local commands passed by DMTCMX. 1 
SS SS ed 
| MSGPROC | Prepares commands and messages for transmission. 1 


| | Interfaces with DMTNHD to build network header. 1 
Na ere ce enpnmeensens nels c-Src rnnsneneseneemnaonremennenrall 


Figure 2-24. NCM Function Processors 


NCM Line 1/0 Handler Routine: COMSUP 





COMSUP controls all I/O activity on the communications adapter for the 
NJI line driver. It handles both BSC line and channel-to-channel 
communication. This routine receives data from the adapter and passes 
the data to the deblocker routine ($TPGET). COMSUP sends data (which 
has been blocked by the blocker routine, $TPPUT) to a remote systen. 
COMSUP also acknowledges receipt of data over a BSC line using the 
standard BSC control characters. 
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Data received over the communications adapter is placed ina 
teleprocessing (TP) buffer. The size of TP buffers is specified by a 
START command parameter and can be up to 1017 bytes. 


Data contained in TP buffers is deblocked into tanks, which are unit 
buffers of a specific size used to deblock the larger TP buffers. There 
are 15 tanks; these are allocated as they are needed by processors. The 
size of tanks is determined by MULTI-LEAVING control bytes. 


When an NCM function has been requested, the data must he either blocked 
for transmission (if it is data for a remote system) or deblocked for 
processing (if it has been received from a remote system). 


$TPGET receives data from a communications adapter (via the COMSUP 
routine) and allocates tanks to output processors as they are needed. 


$TPPUT receives tanks from input processors, blocks the data in these 
tanks into TP buffers, and gives control to COMSUP to transmit the 
buffers over the adapter. 


Network Header Processor: DMTNHD 


DMTNHD contains routines to process or construct the various network 
header and trailer records used by the NJI/NJE protocol. The network 
header records are read by another non VM/370 NJI system that uses then 
to reconstruct information about the files sent from RSCS. There are 
two major types of network header records: job headers and data set 
headers. DSECTs describing these header and trailer records are shown 
in Section 5. Other NJE/NJI systems also make use of the same mapping 
shown in these DSECTs. The header and trailer routines in DMTNHD are 
entered from the processors in DMTNCM whenever network header or trailer 
processing is required. 


Command and Message Processing 


——. ———— 





Two routines are used to process network commands and messages. 

DMTNHDMI is entered from $WRTN1 to interpret the header record whenever 
a command or message is received from a remote system. From the 
information in this header record a routing request element is built and 
then passed by DMTNCM to DMTRGX for processing. If a global network 
command is recognized, it is translated into the appropriate RSCS 
command, if the command destination specifies the local RSCS. 


DMTNHDMO is entered whenever a network command or message to be 


transmitted is processed by MSGPROC in DMTNCM, The network header is 
constructed from information contained in the routing alert element. 


File Header 


Ino 


ecord Output Processing 











Entry point DMTNHDHO is entered from $PRTN1 and $URTN1 each time a 
network header record is received by the output or job file processors 
in DMTNCM. A subroutine is then entered when a valid NJI/NJE header 
record is found. 
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Routine HOJOB is entered when a job header record is found. The header 
record is saved for later processing, various default fields are created 
in the output log slot, and message DMTNHD917I is issued. 


HODATSET is entered each time a data set header is encountered. The 
fields in the default tag slot are updated from the fields in the data 
set header record. The logical output device table is then searched via 
a call to DVASSIGN. This routine will assign this data set to a device 
for processing, by comparing the attributes of the new data set with 
ones already existing. If an open data set is not found, a new device 
is obtained via a call to OPENADEV. This routine obtains, through a 
call to DMTAXS, a new spool device. Once a new device is obtained, 
routine HDROUT is called to output the job header as a segmented NOP 
spool record. 


When the job trailer record is encountered, subroutine HOJOBTRL is 


entered. All open data sets are closed after the job trailer record is 
written to the spool systen. 


File Header Record Input Processing 





Routines DMTNHDJH, DMTNHDDH, and DMTNHDJT are entered from processor 
$RRIN1 in DMTNCM when a file to be entered into the NJI line driver does 
not already contain NJI/NJE header records. DMTNHDJH and DMTNHDJT 
create the job header and trailer records from the information in the 
input tag slot. The data set header creation routine DMTNHDDH creates 
the data set header record from the input tag slot along with data from 
calls to the TAGSCAN routine to scan the user's tag data record for 
NJI/NJE parameters. Because non VM/370 systems generally distingush 
between job files and output files, RSCS must make a distinction between 
such files before they are sent to another NJI/NJE system. The terminal 
user specifies whether he wants his files to be JOB files or output 
files in the tag record before he sends them to RSCS to be sent to 
another system. DMTNHD then scans this tag record to determine the type 
of file to be sent and obtains other information about the file that it 
puts in the NJI/NJE header records, 


DMTNJI Initialization Module: DMINIT 





This module is entered from DMTNCM during line driver initialization. 
It performs the following functions: 


1. Scans the supplied parameter string and create a network SIGNONW 
record from the information obtained from the scan. 


2e Sets task alert asynchronous erit. 


3. Obtains storage and builds the teleprocessing buffer queue and unit 
record tank queue. 


When control is returned to DMTNCM, the page containing DMTWNIT is freed 
via a call to FPAGEREQ in DMTCOM. 
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Modules and Subroutines 
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Program Organization 


Figure 3-1 lists the functions of all RSCS subroutines in order by 


module name. 





Module 
Name 


DATAKE 


DM TASK 


DMTASY 


DMTAXA 


DMTAXM 


j Entry Pt | 


{| /Routine | 


een ee ee ee wee ES gee me ee gee, es ee ee ee ee Oe ee 8 ee ee es ee ee Oe gees OE OS gee 


DMNTAKEEP 


DMTAS KEP 


DMTASYEP 


DMTAXAAC 


DMTAXASE 


DMTAXAPU 


DMTAXARE 


DMTAXATA 


DATAXMEP 


AXSASYIO 


AXSINIT 
AXSCYCLE 





Function | 


Contains the supervisor service that supplies | 
task programs with the receiver interface to ! 
GIVE requests issued by other tasks. A single | 
call causes DMTAKE to first respond to the | 
previously supplied GIVE request and then | 
supply a new GIVE request to the task for its { 
processing. I 
| 
A service routine that creates new tasks and | 
deletes existing tasks executed by the MSUP { 
dispatcher. The entry to DMTASK is via a BALR | 
instruction from task programming. Any entry | 
into DMTASK causes the calling task's execution | 
to be suspended through the freeze SVC function. | 
t 
A supervisor service module that starts and ends] 
asynchronous exit requests for task programs. { 
This routine handles asynchronous exit requests 
for asynchronous exit requests for I/0 
interruptions, and alert exit requests. 


| 
NOP entry -- No accounting record is cut when a } 
file is accepted. ! 
I 
Cuts a send accounting record when all copies of 
an input file have been sent. 
I 
I 


I 

| 

| 

{ 
I 

{ 
NOP entry -- No accounting record is cut when a | 
file is purged by purge command. | 
| 
Cuts a receive accounting record when an output | 
file is written to the spool systen. { 
| 

{ 


NOP entry -- user tag priority of a file is left 
unchanged. 


1 

| 
Controls the interface of the line drivers to 
the ¥M/370 spool file system, enqueues files for| 
transmission, and processes commands that { 
Banipulate spool files, 
Start of asynchronous exit routine; signals | 
arrival of a request for asynchronous exit. | 
Initializes the AXS task. | 
Looks for work to do by examining the synch | 
locks associated with the AXS task. 


eee enn Sl nnn ee | 


Figure 3-1. 


RSCS Modules and Their Subroutines (Part 1 of 13) 
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Module | Entry Pt | 
Nane {| /Routine | Function 

Se | 


REQXEQ Scans the request table for a match and branches| 
to the appropriate subroutine, depending on the | 
request code. 

CMDPROC Executes AXS commands from the command buffer 
passed on by an alert exit from DMTREX. 

OPENIN Starts spool file processing. 

CLOSEOUT Ends processing for output files. 

CLOSIN Terminate spool file processing. 


MSG Sets the MSG request element. The MSG request 
element is passed via GIVE/TAKE to the message 
manager, DMTMGX. The code associated with 
entry points in this module format the MSG 
element variable areas in various ways and 

exit finally to MSG. 

Converts and validates a hex string. 

Converts and validates a decimal string. 
Converts a hex fullword to decimal and generates 
an EBCDIC representation of it, suppresses 
leading zeros to a minimum count, which is 
optionally supplied by the caller. 

Converts EBCDIC to the Systemn/370 TOD value. 
Converts System/370 TOD to EBCDIC date and time. 
Gets inactive successor spool file. 

Inspects newly arrived files. 

Brings in a link's pending tags. 

GETROUTE Gets a routing table entry. 

GETLINK Gets link table entry. 


I | 
I | 
1 | 
I | 
| I 
I l 
l | 
{ I 
! | 
I I 
( ! 
l l 
I I 
| ! 
| HEXGET | 
{ | 
{ I 
I ! 
I | 
I | 
I I 
! ! 
I | 
{ I 
| | 
i { 
I { 
{ GETSLOT | Gets a free tag queue element. 
| l 
I | 
I l 
| { 
| | 
! I 
| I 
{ | 
| 1 
{ { 
1 | 
| I 
I | 
I I 
l | 
I I 
I | 
! I 
! ! 
I I 
{ | 
I I 
l { 
| I 
I I 
I I 
I { 


DECGET . 
DECPOUT 


TODS370 
TODEBCD 
GSUCCESS 
ACCEPT 
UNPEND 


i 

| 

| 

| 

| 

| 

| 

1 

| 

{ 

| 

| 

I 

| 

| 

! 

| 

i 

i 

| 

1 

| 

| 

I 

| 

FR EESLOT Returns a tag queue element. | 
TAGGEN Builds a file tag from hypervisor information. | 
TAGPLACE Sets a file tag into a link queue immediately { 
before the first tag of numerically higher | 

priority (lower processing priority) . | 

Reorders file queue after System | 
reconfiguration. | 
Selects a file to be read from a link queue. | 
Locates a file with spoolid matching the one | 
supplied by the caller, within the internal | 
file tag queues. \ 
Dequeues an active file tag, closes and 1 
re-enqueues input files, closes and purges | 
output files. | 
Gets a virtual spool device. | 
Undefines a virtual spool device. | 
Changes VWM/370 file attributes. | 
Issues the V¥M/370 CLOSE command for a device. | 

Purges an inactive reader file from the VM/370 | 

spool. | 

Transfers an incorrectly addressed file back to | 

its original user. | 

Sets VM/370 virtual spool device options. i 

Sets a VWM/370 tag for a virtual spool device. | 

Sets a ¥M/370 tag for a virtual spool device ( 

spooled to a user. { 

VTAGF Sets a WM/370 tag for an inactive spool file. | 


| Se en Se | 


REORDER 


FILSELEC 
TAGFIND 


TAGCLOSE 


DEFINE 
DETACH 
VC HANGE 
VCLOSE 
VPURGE 


VIRANSFR 
VS POOL 


VTAGD 


i 
I 
t 
| 
| 
I 
1 
| 
1 
I 
| 
{ 
| 
| 
| 
! 
( 
I 
{ 
| 
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{ Module | Entry Pt | ! 
| Name { /Routine | Function | 
amma me cma (ce aa arr, | 
| DMTCMX | DMTCMXEP | This module is part of the REX system control | 
{ { | task; it is called in several places in DMTREX, | 
| | | (the main REX control routine). DMTCMX accepts | 
| | {| an EBCDIC string and executes the RSCS command | 
| | { that the string represents. | 
| {| CMXHIT { Calls the necessary individual command | 
| | ! processing routine. \ 
| {| CMXALERT | Passes a command element to another task via | 
i j j the alert task-to-task communications interface. | 
| | CMXREORD | To pass to DMTAXS a REORD alert element. | 
{ {| CMXULOOP | Check for looping responses to user. | 
| {| KEYWDGET | Decodes the next keyword on the input command | 
I | | line, I 
{ { LTABGET { Finds the Link tabie entry itpiied by the first j 
| | | keyword in the command line described by the l 
{ I { calling routine's register parameters. | 
| | RTABGET | Find the root table entry implied by the first | 
I j | keyword in the command line described by the | 
| | | calling routine's register parameters. { 
| | HEXGET | Converts and validates a hex string. { 
{ { DECPUT {| Converts a hex fullword to decimal and generates| 
| | | an EBCDIC representation of it. It suppresses | 
H j | leading zeros to a minimum count, which is | 
| { { optionally supplied by the calling routine. l 
{| | FILGET {| Locates a file, within the internal file tag ! 
{ I | queues with a spoolid matching that supplied by | 
| | { the calling routine. { 
| | TODEBCD | Converts System/370 TOD to EBCDIC date and tine. | 
{ | PARMGET | Scans an EBCDIC line and frames the next I 
{ | { parameter on the line. | 
| | FINDTAGQ | Finds a file tag with the same destination as | 
{ | { the ROUTDEST in the routing table. | 
{ | I | 
{ DHTCOH {| DHTCOREP j Contains various reentrant routines used by RSCS| 
{ { {| tasks, { 
| | GETLINK | Scans the link table chain and returns a link | 
{ { { table address. | 
{ | GETROUTE | Scans the link table chain and the routing table| 
| | 1] chain to select the next link for transmission. | 
| | GETPAGE | Gets a free page of virtual storage. 1 
| | FREEPAGE { Returns a page of virtual storage. i 
{ {| MFI | Stacks message elements in a LIFO stack for | 
| l | later processing. If no room is available in | 
I | { the current page, a new page is fetched if l 
{ | { at least five free pages remain. If five free | 
{ | | pages are not remaining, an error condition is | 
{ { | returned. All tasks except REX are allowed only| 
| | | three pages of storage to stack messages. | 
| | MFO | Unstacks message elements from the message queue] 
t { | for this task. If none are queued, an error { 
| | { condition is returned. | 
| | TODEBCD { Converts Systea/370 TOD to EBCDIC date and time. | 
| | TODS370 {| Converts EBCDIC to System/370 TOD. | 
I | RCMSOPEN { Initializes reading of a CMS file. | 
I {| RCMSGET [| Gets the next CMS file iten. | 
I | GETSUPAG | Allocates a page of virtual storage for super- | 
I I I I 


visor use. 
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Entry Pt 
/ROutine 


DMTCREEP 


DMTDSPEP 


DATEXTEP 


DMTGIVEP 


DATINI 


DMTIOMEP 


DMTIRXEP 


GENVNET 
GETPARM 


PARMGET 


DECPUT 
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Function 





Creates new tasks under MSUP LOAD + QRQ. 


This module is the MSUP dispatcher; it is 
entered when an exit occurs from supervisor 
functions that were entered following an inter- 
ruption or that issued the freeze SVC function. 
DMTDSP must be entered with all PSW masks off 
(except for the machine check mask). 


This modvle is the MSUP external interruption 
handler; it receives control directly on an 
external interrupt and saves the status of the 
executing task if one was interrupted. 


This is a supervisor service routine that 
enqueues GIVE requests from tasks to be 
delivered to other tasks by DMTAKE. 


Receives control after initial loading of RSCS, 
and performs general initialization functions 
common to all parts of RSCS. 


DMTINI writes a copy of the initial load to 
DASD, according to operator instructions, when 
RSCS is initial program loaded from the 
generation IPL deck. When IPL disk writing is 
complete, a masked off wait state PSW is loaded. 


Following IPL from PSCS system residence DASD, 
DMTINI finishes reading the saved RSCS load. 


When IPL disk reading or writing is complete, 
DMTINI passes control to DMTMIN. 


This module contains both the MSUP I/O interrupt 
handler and the task I/O service routine. The 
I/O service provided by DMTIOM to the task 
programs includes sequential subchannel 
scheduling, channel program execution, auto- 
matic sense execution on unit check when 
requested, return of all pertinent information 
regarding the execution of the channel progran, 
and notification via a POST upon completion of 
the channel progran. 


This module performs all non-MSUP oriented 
RSCS initialization. 

Builds RSCS system tables from directory. 
Locates next parameter on input record, and 
performs preliminary validity checking. 

Scans a character string left to,right, and 
frames the first parameter (a substring of 
non-delimiters enclosed by delimiters or 
string boundaries on the left and right). 
Converts a hex fullword to decimal and generates 
an EBCDIC representation of it. It suppresses 
leading zeros to a minimum count, which is 
optionally supplied by the calling routine. 


an a ir en ener etn cellent rene rete rr a 


Figure 3-1. 


RSCS Modules and Their Subroutines (Part 4 of 13) 


104 IBM VM/370: RSCS Networking Logic 


-——_—___-+4 


ee ee ee ee 


Licensed Material - Property of IBM 


fee et ee 


Module 
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DMTLAX 


DMTIMGX 


DMTMIN 


DMTMSG 


DMTNCN 





Entry Pt 
/Routine 


CONW 


MSG 


DMTLAXEP 


DMTMGXEP 


DMTMINEP 


DMTMSGEP 


DMTNCMEP 


NCMINIT 


ISIO 


ASYNEXIT 


SSTART 


$CRIN1 


—T 


Function 


Validates and converts EBCDIC hexadecimal 
input numbers to binary. 

Validates and converts EBCDIC decimal input 
numbers to binary. 

Sequentially reads the directory file 

(RSCS DIRECT) and returns a data line or error 
condition to the caller. 

Generates a numbered operator message by 
editing the message according to CP EMSG 
setting, calling CONW to write the message 

on the console, and returning to the caller. 
Writes a line to the RSCS operator console and 
provides console support until normal DMTREX 
console manager hegins nrocessina. 





Stacks a message for later output. 


This routine is the line allocation task for 
RSCS. Most Of this routine functions as an 
asynchronous exit being alerted by DMTREX. 


Takes a message request buffer and builds the 
message from the information in that buffer and 
the message definition found in DMTMSG. 


Performs basic MSUP initialization operations, 
deletes itself, and issues the first call to the 
MSUP dispatcher to begin normal operations. 


Contains a list of error messages to be used 
externally by DMTMGX. This module contains no 
executable code. 


This line driver communicates with NJI/NJE 
systems on BSC lines or channel-to-channel 
adapters. 

Initializes various parameters needed by 
DMTNCM. Saves its link table address, 
initializes output tags, and calls DMTNIT to 
complete initialization. 

Performs the enable sequence on the 
communications line, analyzes the response 
received, and when correct, writes the 

"line connected" message, 

This is the alert exit entered by DMTSIG. Two 
tasks may alert this line driver: DMTREX when a 
command has been entered for the DMTNCM line 
driver to process, or DMTAXS to asynchronously 
notify DMTNCM a file has arrived for 
transmission. 

This is the supervisor routine for DMTNCM. The 
commutator will cycle looking for a routine to 
enter until all commutator entries are closed; 
then it will wait on a synch lock list to be 
posted. 

Dequeues a tank from its tank queue and 
performs the action requested by the control 
record in the dequeued tank. 
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Dequeves a tank from its tank queue, obtains { 
a new output spool device if needed from DMTAXS, | 
and outputs the tank to a virtual printer. { 
Degqueves a tank from its tank queue, obtains 

a new output spool device if needed from DMTAXS, 
and outputs the tank to a virtual punch. 

Inputs files from the VM/370 spool systen, 
deblocks them into individual records, and 

issues a call to $PUT to block the record into a 
transmission buffer. 

This routine is the interface to DMTAXS for 
getting files to transmit, and it purges those 
files when transmission is complete. 

Deblocks records from the VM/370 page spool 
buffers. It returns the deblocked record 

in the RCTTDATA buffer. 

Processes received commands and messages 

and calls DMTNHD for processing. The records 
are dequeued from the console TCT. 

Executes commands passed to it in the 

CMDRESP buffer after an alert from DMTREX 
indicating a command has been entered. 

This routine is entered when the MSGECB is 
posted by this task's asynchronous exit, 
indicating messages are queued for this task. 
These messages are unstacked from the message 
queue by repeated calls to GMSGREQ and 

queued for transmission. 

Prepares and sends requests to the specialized 
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AXSGET 
VMDEBLOK 
SWRIN1 
CMDPROC 


MSGPROC 
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operator's console. { 

$STPPUT Takes a line and packs it into a telecommunica- | 
tion buffer. When a buffer is filled, it is { 
queued onto $0UTBUF for processing by COMSUP. | 
Deblocks received telecommunications buffers | 
into tanks and queues the tank onto the { 
appropriate processor's TCTTANK queue. ! 
Performs all I/O on the communications line. ! 
It dequeues TP buffers from $00TBUF for | 
transmission and queues received TP buffers | 
onto the $INBUF queue for deblocking by $TPGET. | 
Analyzes all errors on the communication line | 
and takes corrective action depending on the | 
type of error. I 
I 

| 

| 

1 

I 

| 

{ 

! 

I 

| 

1 

I 

| 
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STPGET 


COMSUP 


CERROR 


DMTNHD DMT NHDMI 
DMTNHDMO 
DMT NHDHO 
DVASSIGN 


OPENADEV 


Edits network messages. 

Network command processor. 

Network output header processor. 

Assigns a data set header to an output device. 
Opens a spool output device with 
characteristics defined in the output tag. 
Outputs NJE header record in 80-byte segments 
into the VM/370 spool systen. 

Builds a job header record from multiple 
segments. 

Job header creation routine. 

DM TNHDDH Network data set header creation routine. 


DMTNHDIT Network job trailer header creation routine. 
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Function 


Scans user tag data for NJE forms keywords. 
Prepares and sends requests to REX for 
issuance of messages. 

Input line scanning subroutine. 

Validates and converts EBCDIC hexadecimal 
input numbers to binary. 

Validates and converts EBCDIC decimal input 
numbers to binary. 


This module is the initialization module for 
the DMTNJI line driver. From the parameters 
passed to it at line driver initialization, it 
builds buffers and constructs initial SIGNON 
records. 

Initializes the various parameters needed 

by DMTNIT. Saves its link table address, 
initilizes output tags, and constructs the 
SIGNON card from information on the PARM field 
of the START command. 

Builds TP and unit buffer for the DMTNJI line 
driver. 

Scans a character string left to right, and 
frames the first parameter (a substring of 
non-delimiters enclosed by delimiters or string 
boundaries on the left and right.) 

Validates and converts EBCDIC hexadecimal input 
numbers to binary. 

Validates and converts EBCDIC decimal input 
numbers to binary. 

Prepares and sends requests to REX for 
issuance of messages. 


This module is the line driver that supports 
the 2770, 2780, 3770; and 3780 compatible 
nonprogrammable terminals. 

Maintains a cyclic control of the DMTWPT task 
on both sending and receiving operations. 

Sends the BSC end-of-transmission character 
(EOT) on the line to the remote terminal. 
Initializes the line output buffer with the 
correct BSC character set, depending on the 
type of output file and features available at 
the terminal. 

Requests the supervisor to execute I/0 
operations. After starting the I/O operations, 
XECUTE waits for either a command to be entered 
or the completion of the requested I/0 
operation. 

Executes (by calling XECUTE) I/0 operations on 
the BSC line and checks the results. LINEIO 
then flags any errors and normally returns to 
the caller. 

Prepares the line output buffer to be 
transmitted to the remote terminal. 

Analyzes the response obtained from each buffer 
transmission and takes the appropriate action. 
Deblocks received TP buffers and writes the 
deblocked record to the VM/370 spool systen. 
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| Name {| /Routine 
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Function 


Verifies the content of each received TP buffer, 
and constructs an appropriate reply if the 
buffer is in error. 

Passes commands received from the remote card 
reader to the RSCS command processor. 

Executes commands passed to it in the CMDRESP 
buffer after an alert from DMTREX indicates 
that a command has been entered. 

Unstacks messages from the task message queue 
and transmits them to the remote terminal 
printer. 

Prepares and sends requests to the specialized 
task REX to write console messages. 

Provides, record by record, the separator and 
header for print files and the header card for 
punch files. 

Saves the caller's registers for a call to 
VMSB2CP; upon return from VMSB2CP, it sets the 
return code and returns to the original caller. 
Deblocks the VM/370 spool page buffers into an 
unpacked buffer (PACKBLK). 

Requests AXS to open, close, and delete the 
spool files that the NPT task is processing. 
Converts System/370 TOD to EBCDIC date and time. 
Scans character strings to find delimiters. 
Initialization routine for NPT. 

NPT sign-on routine. 

Writes the terminal I/O error message and 
terminates the task. 

Terminates the NPT task. 


Functions as a remote VSE/POWER system using 
the VSE/POWER MULTI-LEAVING transmission 
protocol. 

This routine initializes the various parameters 
needed by DMTPOW. It saves the link table 
address and initialized output tags. 

Performs the enable sequence on the 
communications line and analyzes the response 
received; if the response is correct, it 
writes the "line connected" message. 

This is the alert exit entered by DMTSIG. Two 
tasks may alert this line driver: 

e DMTREX - When a command has been entered 
for processing by the DMTPOW line driver. 

e DMTAXS -— When DMTAXS must asynchronously 
notify DMTPOW that a file has arrived for 
transmission. 

This is the supervisor routine for DMTPOW. The 
commutator cycles while looking for a routine to 
enter until all commutator entries are closed. 
It then waits for a synch lock list to be 
posted. 

Dequeves tanks from its tank queue and performs 
the action requested by the control record in 
the dequeued tank. 
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| Name j /Routine | 
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$PRITN 1 


SURTN1 


SRRIN1 


AXSGET 


SWRIN 1 


$MRTN1 


MSG 


$TPPUT 


$TPGET 


COMSUP 


CERROR 


VM DEBLOK 


CMDPROC 


MSG PROC 


PARMGET 


| 
Function i 


Dequeues tanks from its tank queue, obtains a { 
new output spool device, if needed, from DMTAXS,] 
and sends the tank to a virtual printer. { 
Dequeues tanks from its tank queue, obtains a | 
new output spool device, if needed, from DMTAXS, | 
and sends the tank to a virtual punch. | 
Reads files from the VM/270 spool file systen, | 
deblocks the files into 132-byte records, and i 
issues a call to $TPPUT (via $PUT) to block the | 
record into a transmission buffer. | 
This routine is the interface to DMTAXS; it gets| 
files ready to transmit and purges those files | 
when transmission is complete. | 
This is the deblock routine for the VM/370 page ] 
spool buffers. It returns the deblocked record | 
in the RCTTDTA1 buffer. { 
This routine writes received VSE/POWER commands | 
to the RSCS operator. | 
This routine writes received VSE/POWER messages | 
to the RSCS operator. { 
Executes commands passed to it in the CMDRESP | 
buffer after an alert from DMTREX indicating { 
that a command was entered. | 
Entered when the MSGECB is posted by this task's| 
asynchronous exit indicating messages are in the] 
message queue for this task. These messages are| 
unstacked from the message queue by repeated { 
calls to GMSGREQ and queued for transmission. t 
Prepares and sends message requests to REX. | 
Scans lines and tests for delimiters. 1 
Takes a line and packs it into a telecommunica- | 
tion buffer. When the buffer is filled, it is | 
queued onto $OUTBUF for processing by COMSUP. | 
Deblocks received telecommunications buffers | 
into tanks and queves the tank onto the | 
appropriate processor's TCTTANK queue. | 
Processes all I/0 on the communications line. | 
It dequeues buffers from $OUTBUF for transmis- | 
sion and queues received buffers onto the | 
SINBUF queue for deblocking by $TPGET. | 
Analyzes all errors on the communications line | 
and takes corrective action depending on the | 
type of error. { 
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{| Module {| Entry Pt }{ | 
{ Name { /Routine | Function | 
{| DMTPRE | DMTPREFP | RSCS preloader utility program (see Appendix B | 
| | { for details). I 
! t 1 | 
1 DMTPST | DMTPSTEP | This service routine may be called from anywhere| 
| | | in RSCS. DMTPST signals the completion of an | 
| { | event by posting the event's associated synch { 
| | | lock. This routine is entirely reentrant and | 
| | {| does not change the state of the running PSW. | 
{ I | | 
1 DMNTQRQ | DMTORQEP | Manages the MSUP supervisor status queue for | 
{ | ] other MSUP functions. DMTQRQ is for use { 
| | | within the supervisor and must be entered with | 
{ | { all PSW masks off (except machine check). | 
| { \ | 
| DMTREX | DMTREXEP | This routine is the controlling supervisor task; | 
] | {| DMTREX, DMTCMX, DMTMGX, DMTSYS, DMTCOM, DMIMSG, | 
| | | and DMTCRE make up the REX supervisor task. | 
Hi | DMTREXIN { Performs the initialization for the DMTREX task. | 
| { REXCYCLE | Monitors a list of synch locks when looking for | 
| | | work for DMTREX to perforn. | 
| | REXPCHEX | Processes program checks. | 
| { REXITERM | Entered when RSCS initialization fails. Issues | 
| { | the initialization failure message, dumps the ] 
| { | contents of main storage, types any remaining | 
i | | messages, and loads a disabled wait state PSW. | 
| | REQXEQ { Scans the function table and calls either | 
| { | DMTCMX or DMTMGX as appropriate. ! 
| | INTCMD { Internal command processor. | 
| { DEACT | Deactivates the link table entry. | 
I {| DMTREXEC | Process exec file content. | 
| | DMTREXTR | Executes the terminate function for the FORCE l 
] | } command. ; { 
{ { MSG { Prepares message reguests and calls DMTMGX. { 
{ {| TIMERSET | Supports timer alert requests. | 
| {| TERMINAT | Terminates a specified task. | 
{ | QUIESCE | Executes as task code for a task in the process | 
| 1 | of termination. Looks for any outstanding I/O | 
| | { for the terminating task. If any outstanding | 
{ { { I/O is found, issues HIO and waits for comple- | 
| { { tion; upon completion it terminates the task. | 
I | | | 
{| DMTRGX | DMTRGXEP | Handles the command and message routing request | 
| | , | elements. | 
| | RGXCMD { Interfaces a CMD routing request element with | 
I | | DMTCMX. { 
| | RGXMSG | Writes message DMTxxx170I or DMTxxx171I from l 
| | | message routing request element. 
] | RGXNTHRE | Processes CMD/MSG routing request element for { 
{ | {| store-and-forward. | 
| {| RGXDOIT | Message routing interface. ! 
| | RGXMSGER { Processes non-zero return code from DMTMGX. { 
\ I | | 
{ DMTSIG | DMTSIGEP | Performs a task alert exit for a requesting | 
| | I | 


Figure 3-1. 


110 


task. 


RSCS Modules and Their Subroutines (Part 10 of 13) 


IBM VM/370: RSCS Networking Logic 


Licensed Material - Property of IBM 


Co ee ee T 
| Module | Entry Pt | 


| Name | /Routine 


DMTSML DMTSMLEP 


SMLINIT 


ISTO 


SSTART 


SCRIN 1 


$PRIN1 


SURTN1 


SIRTN1 


SUSREXIT 


SRRTN1 


AXSGET 


VM DEBLOK 


HEADPREP 


TODEBCD 
S$WRIN1 


| 
Function | 


Functions as an RJE workstation into a remote 
system using the MULTI-LEAVING transmission 
protocol. It can also function as a host to a 
remote programmable workstation supporting a 
Systen/370, System/3, Model 20, 1130, 2922, or 
other compatible workstation systems. 
Initializes various parameters for DMTSML. 
Saves the link table address, initializes 
output tags, constructs the SIGNON card 

from the operand field of the START command. 
Performs the enable sequence on the 
communications line and analyzes the response 
received; if the response is correct, it 
writes the "line connected" message. 


i 
| 
| 
I 
| 
| 
| 
! 
! 
i 
| 
I 
| 
{ 
{ 
tasks may alert this line driver: { 
e DMTREX - When a command has been entered | 
for processing by the DMTSML line driver. | 

e DMTAXS - When DATAXS must asynchronously | 
notify DMTSML that a file has arrived for ! 
transmission. | 
This is the supervisor routine for DMTSML. The | 
commutator cycles while looking for a routine to| 
enter until all commutator entries are closed. | 
It then waits for a synch lock list to be | 
posted. { 
Dequeuves tanks from its tank queue and performs | 
the action requested by the control record in | 
the dequeued tank. I 
Dequeves tanks from its tank queue, obtains a | 
hew output spool device, if needed, from DMTAXS, | 
and sends the tank to a virtual printer. { 
Dequeues tanks from its tank queue, obtains a | 
new output spool device, if needed, from DMTAXS,| 
! 

{ 

{ 

| 

I 

| 

I 

| 

{ 
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Dequeues tanks from its tank queue, obtains a 
new output spool device, if needed, from DMTAXS, 
and sends the tank to a virtual punch. 

Validates the ID card in the front of decks read 
in from a remote card reader. 

Reads files from the VM/370 spool file systen, 
deblocks the files into 132-byte records, and 
issues a call to $TPPUT (via $PUT) to block the | 
record into a transmission buffer. { 
This routine is the interface to DMTAXS; it gets| 
files ready to transmit and purges those files | 
when transmission is complete. | 
This is the deblock routine for the V#/370 page | 
spool buffers. It returns the deblocked record | 
in the RCTTDTA1 buffer. 

Provides, one record after the other, the 
separator and header for print files and the 
header card for punch files. 

Converts System/370 TOD to EBCDIC date and tine. | 
In RJE mode, writes received messages to the | 
RSCS operator. In HOST mode, passes commands to| 
DMTREX. These commands or messages are dequeued| 
from console TCT. I 
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| Module 
I Name 


DMTSTO 


DMTSVC 


DMTVEC 


DMTVMB 


{ 
I 
I 
{ 
I 
| 
| 
l 
{ 
I 
| 
1 
| 
| 
I 
| 
{ 
! 
i 
| 
I 
! 
I 
I 
! 
1 
I 
l 
{ 
I 
I 
| 
l 
I 
I 
1 
! 
f 
l 
I 
| 
| 
I 
{ 
! 
| 
l 
l 
l 
| 
1 
I 
i 
I 
! 
I 


Entry Pt | 
/Routine | 


CM DPROC 


MSGPROC 


MSG 
PARMGET 
STPPUT 


ST PGET 


COMSUP 
CERROR 
DMTSTOEP 
DA TSVCEP 


DMTVECEP 


XECUTE 
LINEIO 
GETBLOCK 
PUTBLOCK 


MSGRECV 
MSG 
CMDPROC 


SVMRINIT 
AXSGET 
TO DEBCD 
VARTILT 


1 
| 
{ 
i 
1 
i 
I 
| 
| 
I 
{ 
1 
! 
1 
| 
I 
| 
{ 
{ 
I 
{ 
{ 
| 
I 
| 
! 
\ 
| 
I 
| 
I 
1 
| 
| 
| 
| 
I 
| 
| 
| 
| 
| 
I 
I 
I 
I 
! 
| 
I 
{ 
| 
I 
| 
! 
I 
MSGTRANS | 
I 


Function | 


Executes commands passed to it in the CMDRESP | 
buffer after an alert from DMTREX indicating | 
that a command was entered. ] 
Entered when the MSGECB is posted by this task's| 
asynchronous exit indicating messages are in the| 
message queue for this task. These messages are| 
unstacked from the message queue by repeated 
calls to GMSGREQ and queued for transmission. 
Prepares and sends message requests to REX. 
Scans lines and tests for delimiters. 

Takes a line and packs it into a telecommunica- 
tion buffer. When the buffer is filled, it is 
queued onto $0UTBUF for processing by COMSUP. 
Deblocks received telecommunications buffers 
into tanks and queues the tank onto the 
appropriate processor's TCTTANK queue. 
Processes all I/O on the communications line. 
It dequeues buffers from $00TBUF for transmis- 
sion and queues received buffers onto the 
SINBUF queue for deblocking by STPGET. 

Analyzes all errors on the communications line 
and takes corrective action depending on the 
type of error. 


Reserves pages of free storage by calling 
task programs that free storage pages by 
clearing the associated map byte to zero 

in the main storage map. 

This module is the MSUP interrupt handler; it 
receives control directly when an SVC 
interrupt occurs. 


Describes the fixed address storage utilization 
for MSUP, beginning at main storage address 
X'200'. System/370 architecture defines the 
first 512 bytes of main storage, and MSUP uses 
this area as defined. This area is not 
assembled in the DMTVEC module to facilitate 
initial system loading. This area is 
initialized by DMTINI at IPL. 


Performs I/O on the supplied I/0 block. 
Performs I/O and analysis. 

Processes input files for transmission. 
Processes received data buffer outputting to 
spool systen. 

Process received commands and messages. 
Prepares and sends message requests to REX. 
Executes commands passed to it in the 
CMDRESP buffer after an alert from DMTREX 
indicates that a command has been entered. 
Initializes line driver. 

Provides interface to AXS for input files. 
Converts Systen/370 TOD to EBCDIC date and time.| 
Terminates line driver task. | 
Unstacks MSG and command element and blocks for | 
transmission. | 
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{| Module i Entry Pt 


Nane 


DATVMC 


DMTWAT 


/Routine 
VMSB2CP 
PACK 
CTCGO 


XECUTE 


LINETO 


GETBLOCK 


MSGTRANS 
PUT BLOCK 


MSGRECV 
CMD PROC 


MSG 


MAKEBLOC 
AXSGET 


TODEBCD 
PARMGET 
CONVBLK 


CTCINIT 


CTCERROR . 


CTCTERA 


DMTWATEP 


a 
’ 


Function : { 


Deblocks VM/370 4K spool page buffer. 

Packs a line into transmission buffer format. 
This line driver supports the use of a channel- 
to-channel adapter between two processors 
running VM/370. This routine requests the 
supervisor to execute I/0 operations. After 
initiating the I/O operation, the routine waits 
for either a command to be entered or the 
completion of the requested I/O operation. 
Executes (calling XECUTE) I/O operations on the 
vVMC and checks the final state, consequently 
setting the IOERR flag in the DEVFLAG byte. 
Processes input files from the V¥M/370 spool 
file systen. 

Builds message buffer for transmission. 
Relocates received spool block records, and 
sends them to the VWM/370 spool system. 
Processes received commands and messages. 
Executes commands passed to it in the CMDRESP 
buffer after an alert from DMTREX indicating 
that a command has been entered. 
Prepares and sends requests to the specialized 
task REX, to write messages on the operator's 
console. 

Sets up for a call to VMSB2CP. 

Passes requests to A¥S to open, close, and 
delete the spool files that the VmMC task is 
processing. 

Converts Systen/370 TOD to EBCDIC date and tine. | 
Line scanning subroutine. I 
Converts a spool page buffer from real reader to] 
virtual unit record output format. 

VMC initialization routine. 

Writes the terminal I/O error message and calls 
CTCT ERA. 

Terminates the VMC task. 


Called directly from task programs by a BALR 
instruction. It provides event synchronization 
by suspending a task's execution until some 
specified event is signalled complete by another 
process in the systen. 
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Module-to-Module Execution Transfers (BALRs) 


Figure 3-2 lists the code locations at which control is passed from one 
RSCS routine to another via a BALR instruction. 


| RSCS | 
| Module | 





DMTAKE| 
l 
! 


K 
DOMTASY 
M 


BALR to 
Module 


—_}—_-_—— 


DMTDSP 
DMTPST 
DMTORQ 
DMTDSP 
DMTPST 
DMTQRQ 
DMTQRQ 
DM TORQ 
DMTOQRQ 


DMTQRQ 


DMTDSP 
DMTQRQ 


DMTQRQ 


DMTAKE 
DMTASY 


DMTASY 


DMTAXA 


DMTCOM 
DMTCOM 
DMTCOM 
DMTCOM 


At 
Label 


TAKEXIT 
TAKEMUTE 
TAK FMUTE 
TAEXIT 
TAGP URGE 
TAFREEOK 
TAGP URGE 
TAMAKE 
TAQPTEST 


TASQTEST 


ASEXIT 
ASQEND 


ASQGOT 


AXSACCPT 
AXSIGSET 


AXSIGSET 


DMTA XAAC 
DMTAXASE 
DMTA XAPU 
DMTAXARE 


DM TA XATA 


GETLINK 
OPENIRTY 
CPENCLNK 
TODEBCD 


Conments 


Resumes dispatching; processing of a TAKE 
request is complete. 

Signals a task that it must process a 
TAKE request. 

Frees a GIVE element. 


Resumes 
request 
Signals 


dispatching; processing of a task 
has completed. 

the termination of a task. 

Frees a terminated task element. 

Frees a terminated GIVE element. 

Gets a queue element for a new task. 
Frees requested elements for a terminated 
task. 

Frees an I/O element associated with a 
task being purged. 


Resumes dispatching; processing of an 
asynchronous exit request has completed. 
Gets a free queue element; frees a 
terminated queue element. 
Gets a free queue element; 
terminated queue element. 


frees a 


Takes a request for DMTAXS services from 
another task. 

Requests an asynchronous exit for task 
asynchrononous alerts. 

Requests an asynchronous exit for reader 


X*O0T*. 


Execute the 
Execute the 
Execute the 
Execute the 
routine. 

Execute the 


accept account record routine. 
send account record routine. 
purge account record routine. 
receive account record 


tag priority change routine. 
Gets a link table entry. 

Gets a page of main storage. 
Gets a page of main storage. 


Converts System/370 TOD to EBCDIC date and 
time. 
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{ RSCS | BALR to | At | | 
jModulej Moduie j Label i Comments i 
t+} ————— 1 1 4 
| | DMTGIV | MSGDO | Gives a message element to DMTMGX for { 
| { | {| processing. | 
| {| DMTPST | AXSALRT1 | Signals acceptance of a command to | 
{ | | { process. | 
{ {| DMTPST | AXSASYIO | Signals arrival of a request for an | 
| { ! | asynchronous exit. ! 
j | DMTSIG | ACCEFIND | Alerts a line driver task that a newly | 
| | | | arrived file has been accepted. { 
! ! DMTSTG |! CHANDONE |! Alerts a line driver task. | 
| | DMTWAT | AXSCYCLE ] Waits for a request for DMTAXS services. | 
I | DMTWAT { MSGDO | Waits until processing by DMTGIV has ] 
] | | { completed. | 
I | I | | 
IDMTCMX!] DMTCOM {| QYOLINK | Finds a link table entry. | 
| I I | { 
j | DMTCOM | TODEBCD | Converts a System/370 TOD to EBCDIC date | 
I | | { and time. | 
{ { DMTCRE {| STALNGOT { Creates a line driver task, as specified | 
ij | | { in the START command. | 
j | DMTMGX | CMXDOIT | Writes a message resulting from command ! 
{ { ! |] processing. { 
| | DMTMGX | CMXM001 fj Writes a message showing the number of I 
| | | | free pages in storage. j 
| {| DMTMGX | CMXMO03B | Writes a message showing the command now {| 
| I { {| being executed by RSCS. | 
| | DMTMGX | DISCHARG | Writes a message resulting from DISCONN | 
| | ] | command processing. | 
| {| DMTMGX | OYM654 { Writes a message resulting from QUERY | 
l I I { command processing. { 
| | DMTMGX { QYm655 | Writes a message resulting from QUERY | 
| | | | command processing. | 
| | DMTMGX | QYSYMSG | Writes a message resulting from command | 
| | | | processing. | 
I { DMTREX {| DISCONN J| DIAGNOSE instruction entry to CP console | 
| | i] | function, | 
| | DMTREX | DISCHARG | DIAGNOSE instruction entry to CP console | 
{ { | {| function. | 
| { DMTSIG | CMXALRDY | Alerts a task for command processing. | 
{| DMTSIG | STACREAT | Alerts DMTLAX to validate a line address | 
| | | | used in a START command. { 
| | | | I 
| | DMTMGX | SENDIT | Sends a line of CPQUERY response data back| 
| | | j{ to the issuer. 

{DMITCOM{ DMTDSP | MFIXIT { Requests dispatching of a task for which af 
| | | | message has been stacked for transmission. | 
! | DMTDSP | MFOXIT | Requests dispatching of a task for which a] 
| { { | message has been unstacked for | 
I | I | transmission. I 
| {| DMTSTO { GETPTRY | Requests main storage allocation. | 
| | DMTIOM {| CFILDOIO | Requests the I/O manager to read one DASD |{ 
H | { {| block from a file on a CMS-type system | 
I | { {| disk. | 
| | DMTSTO | CRETRYIT | Requests main storage for the creation of | 
| { { {| a task. ! 
| {| DMTWAT | CFILDOIO | Waits for a read I/O request to complete. | 
| | | | | 
{DMTCRE| DMTASK | CREQTASK | Requests the supervisor to start a new 1 
| | I | 


task. 
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1 RSCS |BALR to | At l | 
{Module| Module {| Label | Comments { 
eae eee aay 
| DMT EXT|( DMTDSP 


| EXTGO { Resumes dispatching; processing of an { 
| | | | external interruption is complete. | 
| I { | | 
{DMTGIV| DMTDSP | GIVEXIT | Resumes dispatching; processing of a GIVE | 
| | | | request is complete. \ 
| | DMTPST | GIVESNIF { Signals a task to begin processing a GIVE | 
| | | {| request. | 
| | DMTQRQ | GIVESCAN | Gets a free queue element. { 
i | | | | 
|DMTINI | DMTDSP | INIQDONE | Dispatches the first task. I 
{ | DMTQORQ | INIQDONE | Initializes the queue of free elements. i] 
I | | | | 
{DMTIOM] DMTDSP | IODISPCH | Resumes dispatching; processing of an I/0 | 
| | { | request is complete. | 
1 | DMTPST | IONORMAL | Signals completion of an I/0 event. | 
{ { DMTPST | IOPUNT {| Signals an error on a request for a queue | 
| | | | element. | 
| | DMTQROQ { DMTIOMRQ | Gets an element for an I/0 request. | 
| { DMTQORQ | IODISMIS | Frees an element used for a SENSE request. | 
| | DMTQRQ | IONORMAL | Frees an element used in an I/O request. | 
j }] DMTQRQ { IOUNITCK | Gets an element for a SENSE request. i 
| I I | | 
{DMTIRX | DMTCRE | | Initiate AXS and LAX tasks. | 
| { DMTASY | | Initializes an asynchronous exit address. | 
{ | DMTCOM |{ IRXBLK | Obtains storage for supervisor use as | 
{ I | {| buffer space. H 
I {| DMTCOM | DIRECT | Open *RSCS DIRECT! H 
1 | DMTCOM { DIRREAD {| Read 'RSCS DIRECT! | 
| | { I | 
| DMTLAX{ DMTASY { LAXINIT | Sets up an asynchronous exit for DMTLAX. | 
l {| DMTWAT | LAXHANG | Terminates DMTLAX. | 
| | ! | | 
[| DMTMIN | | | Initializes MSUP after DMTINI loads it. | 
{ | | | | 
{DMTMGX| DMTCOM | MGXBUILT | Gets a link table entry. l 
{ { DMTCOM | MGXTOCLOC | Stacks a message. | 
I | DMTREX | MGXNOPR | Writes a message to a local VM/370 userid. | 
| | DMTREX | MGXNOVM | Writes a message to the VM/370 operator. | 
| | DMTSIG | MGXBUILT | Alerts an originating task that a message | 
| | | {| has been handled. | 
I { | | I 
|} DMTNPT{| DMTASY | NPTNOPAS | Sets up an asynchronous interrupt for | 
| | { | DMTNPT. I 
I {| DMTCOM { AXSMENQ | Enqueues a message on the message stack | 
| | | | for processing by DMTMGX. | 
| | DMTCOM { MSG2780 | Unstacks a message for transmission toa | 
! { | { remote station. { 
| | DMTCOM | NPTNOPAS | Gets a page of storage for use as DMTNPT | 
{ | | | buffers. 
| | DMTCOM { TODEBCD | Converts System/370 TOD to EBCDIC date | 
| { { | and time. | 
| { DMTGIV {| AXSGET | Requests DMTAXS to open a file. | 
| {| DMTGIV | AXSPURGE | Requests DMTAXS to purge a file. | 
| {| DMTGIV | COMMANDS | Passes a command element to DMTREX for { 
| { | | processing by DMTCMX. { 
| | DMTGIV | KLOGIT | Requests DMTAXS to open the log trace file| 
| | I | 


for output. 
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to 
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| 


[{Module! Module |! 


| 


DMTPOW 


DMTGIV 
DMTGIV 


DMTGIV 
DMTGIV 


DATGIV 
DMTGIV 


DMTIOM 


DMTIOMN 
DMTIOM 


DMTPST 
DMTWAT 


DMTWAT 


DATWAT 
DMTWAT 


DMTWAT 
DMTWAT 
DMTWAT 


DMTWAT 
DMTWAT 


DMTWAT 
DMTWAT 
DMTWAT 


DMTASY 
DMTCOM 


DMTCOM 
DMTCOM 
DMTCOM 
DMTGIV 
DMTGIV 


DMTGIV 
DMTGIV 


At 
Label 


LINEDROP 
LOGCLOSE 


MSG1 
PUTCLS1 


PUTOPEN 
TAS KILL 


LOGCONT 1 


LOGPRINT 
XECUTE 


AXSALRT1 
AXS GET 


AXSP URGE 


COMMANDS 
KLOGIT 


LINEDROP 
LOGCLOSE 
LOGCCNT 1 


MSG1 
PUTCLS1 


PUTOPEN 
TASKILL 
XECQWAIT 


SETNOBUF 
ASYNENQ 


BUFSDONE 
IBLDEUFS 
MSG PROC 
AXS 
AXSGET 


AXS PURGE 
EOJ 


MSG1 


Comments 


Reguests DMTAXS to close a file. 
Requests DMTAXS to close the log trace 
file for output. 

Passes a message element to DMTMGX for 
processing. 
Requests DMTAXS to 
output. 

Requests DMNTAXS to open a file for output. 
Requests DMTREX to terminate the 
requesting NPT line driver. 

Requests an I/O operation for the LOG 
routine. 

Prints a LOG message. 

Requests an I/0 operation (general usage 
by DMTNPT). 

Signals that DMTNPT accepted a command. 
Waits for a request to open a file to 
complete processing. 

Waits for a request to purge a file to 
complete processing. 

Waits for DMTCMX to process a command. 
Waits for completion of a request to open 
the log trace file for processing. 

Waits for a request to close a file to 
complete processing. 


close a file for 


Waits for a request to close the log trace 


file when processing is complete. 

Waits for an I/O operation to complete 
logging processing. 

Waits for message processing to complete. 
Waits for a request to close a file to 
complete processing. 

Waits for completion of a request to open 
a file for processing. 

Waits for task termination processing to 
complete. 

Waits for an I/O operation to complete. 


Sets up an asynchronous exit for DMTPOW. 
Stacks a message to be transmitted by 
DMT POW, 

Gets a page of storage 
tasks. 

Gets a page of storage for DMTPOW TP 
buffers. 

Unstacks a message for 
remote station. 
Requests services of DMTAXS for the POW 
line driver task. 

Requests DMTAXS to give a file for 
transmission. 

Requests DMTAXS to purge a file. 

Requests termination of the POW line 
driver task. 

Gives a message to DMTMGX for processing. 


for DMTPOW 1/0 


transmission to a 
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| RSCS 


[BALR to | 


{Module} Module | 


DMTREX 


DMTIOM 
DMTIOM 


DMTIOM 
DMTIOM 
DMTIOMN 
DATWAT 


DMTWAT 


DMTWAT 


DMTWAT 
DMTWAT 
DMTWAT 
DMTWAT 


DMTWAT 
DMTWAT 
DMTWAT 


DMTAKE 


DMTASK 
DMTASK 
DMTASY 
DMTCMX 


DMTCOM 
DMTCOM 


DMTCRE 
DMTDSP 


DMTDSP 


DMTIOM 
DMTIOM 
DMTIOMN 
DMTMGX 


DMTMGX 
DATPST 
DMTPST 


DMTWAT 
DMTWAT 
DMTWAT 
DMTWAT 


At 
Label 


I27XxIoO 
LOG PRINT 


PCONT4 
RSIO 

UCONT2 
ALLCHK 


AXS 
AXSGET 


AXS PURGE 
DEOJCONT 
DEOJGO 
EOJ 


LOG PRINT 
MSG1 
RISIO1 


REXACCPT 


QUIESE 
TERTKILL 
REXICGOT 


REXFLUSH 
REXOUTRY 


REXICGOT 
REXDQUIT 


REXHEXIT 


REXCONON 
REXFOONF 
REXQUERY 
MSG 


TERMSET 
REXASYN 
REXHALT 


QUIESE 
QUICK 
REXSWAIT 
REXWAIT 


Comments ! 


Performs the initial I/O operation for the 
POW line driver task. 

Requests an I/O operation (logs an I/0 
operation). 

Requests an I/O operation for the printer. 
Requests a start I/O for the adapter. 
Requests an I/O operation for the punch. 
Waits for the DMTPOW synch lock to be 
posted (waits for a request to process). 
Waits for completion of an event by 

DMT AXS. 
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Waits for DMTAXS to purge a file. 

Wait for HDV. 

Wait for disable of adapter. 

Terminates the POW line driver task by 
issuing a terminal WAIT request. 

Waits for I/0 logging to complete. 
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file. | 
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Initializes an asynchronous exit. | 
Pass the Special Message to the Command { 
Processor. | 
Requests DMTMGX to write any queued { 
messages. | 
Removes a message for the message stack 1 
and writes it to the console. | 
Creates the tasks DMTAXS and DMNTLAX. | 
Terminates dispatching due to progran ! 
check. | 
Resumes dispatching after | 
processing. { 
Requests an I/0 operation ! 
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Passes a message element to DMTMGX | 
processing. | 
Writes a task terminated message. | 
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Signals that DMTREX is undispatchable due | 
to program check. l 
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Figure 3-2. 
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1 RSCS |BALR to | At | 

{Module{| Module | ~ Label 1 Comments 

-———— HE > 

| DMTRGX] Process command and message routing 
| | request elements. 


| 

| 
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| { { 

| | | 

{DMTSIG| DMTDSP {| ALSCAN { Resumes dispatching; processing of an | 
| i | ALNOGO | alerted task has completed. | 
I I | I | 
|DMTSML] DMTASY | SETNCBUF | Sets up an asynchronous exit for DMTSML. | 
j | DMTCOM | ASYNENQ | Stacks a message to be transmitted by | 
H ! { } DMTSML. ! 
l | DMTCOM | BUFSDONE | Gets a page of storage for DMTSML I/0 | 
| I { j tasks. i 
| | DMTCOM | IBLDBUFS | Gets a page of storage for DMTSML TP | 
| | | { buffers. l 
| { DMTCOM { MSGPROC1 | Unstacks a message for transmission toa | 
| | { | remote station. | 
i i DMTCOM j TODEBCD | Converts System/3790 TOD to ERBCDIC date H 
| H | | and time. { 
| {| DMTGIV | AXS | Requests services of DMTAXS for the SML | 
{ | | { line driver task. | 
{ | { KLOGIT { Requests DMTAXS to open a log trace output] 
I I { | file. | 
{ { {| LOGCLOSE | Requests DMTAXS to close the log trace { 
| | | {| output file. { 
| | DMTGIV {| AXSGET | Requests DMTAXS to give a file for | 
| | | | transmission. { 
{ | DMTGIV | AXSPURGE | Requests DMTAXS to purge a file. | 
{ {| DMTGIV {| EOJ | Requests termination of the SML line \4 
| | | | driver task. | 
| ! I I | 
i | DMTGIV | MSG1 {| Gives a message to DMTMGX for processing. | 
I {| DMTGIV | WGETT1A | Requests that a message be written to the | 
H | | {| RSCS console; pass a command to DMTREX. | 
{ | DMTIOM | I27XXIO | Performs the initial I/O operation for the| 
| | | { SML line driver task. | 
| | DMTIOM | JOUT1 | Requests an I/O operation; sets up job { 
i i i j processing controls. ' 
| { DMTIOM | PCONT2 | Requests an I/0 operation (sets up printer] 
| | { PLINWNE | controls. { 
| {| DMTIOM | RSIO | Requests a start I/O for the adapter. | 
| ] DMTIOM | UOUT2 | Requests an I/C operation (sets up punch | 
| | { {| controls). | 
| | DMTIOM | WRLOG1 | Requests an I/0 operation (logs an I/O l 
| | | | operation). { 
| {| DMTPST | ASYNRET | Posts the reader synch lock. | 
H | DMTWAT | ALLCHK { Waits for the DMTSML synch lock to be | 
| I | | posted (waits for a request to process). | 
| | DMTWAT | AXS | Waits for completion of an event by { 
| I [ { DMTAXS. I 
| | DMTWAT | AXSGET | Waits for DMTAXS to GIVE a file for { 
| | | | transmission. | 
{ {| DMTWAT | AXSPURGE {| Waits for DMTAXS to purge a file. { 
| {| DMTWAT | EOJ | Terminates the SML line driver task by | 
{ | { | issuing a terminal WAIT request. | 
| | | KLOGIT { Waits for DMTAXS to open a log trace { 
| | | {| output file. 1 
| | | LOGCLOSE | Waits for DMTAXS to close a log trace | 
{ | | l | 


output file. 
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Figure 3-2. Module-to-Module Execution Transfers (BALRS) (Part 6 of 7) 
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{| RSCS |BALR to | At | I 
{Modulej{ Module |{ Label | Comments | 
(a SS SS See 
DMTWAT { MSG1 Waits until GIVE to DMTMGX is complete. 
DMTWAT | RISIO1 Waits for initial SIO for the DMATSML 
line driver to complete. 


| { | | 
| I I | 
| { { { | 
| { DMTWAT | WGET1A | Waits until message processing has | 
| | | { completed. { 
| | DMTWAT | WRLOG1 | Waits for I/O logging to complete. | 
| | I | | 
| DMTSTO| DMTDSP | MAINDONE | Resumes dispatching; a request for a | 
| | | | page of storage has been processed. | 
{ { | | l 
{DMTWAT{ DMTDSP {| WAITGO | Resumes dispatching; processing of a | 
| ] | | WAIT request has completed. | 
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Figure 3-2. Module-to-Module Execution Transfers (BALRsS) (Part 7 of 7) 


Control Flow Diagrams 

Figures 3-3 through 3-11 illustrate the flow of control through the 
routines that make up the folllowing parts of RSCS: 
e Multitasking supervisor MSUP 

e REX system service task 

e AXS system service task 

e SML line driver task 

e NPT line driver task 

e NJI line driver task 

e VMB line driver task 

e vMC line driver task 


e POW line driver task 
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Figure 3-5. Program Organization for the AXS System Service Task 
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Figure 3-6. Program Organization for the SML Line Driver Task 
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Figure 3-9. Program Organization for the VMB Line Driver Task 
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Name 
DMTSIG 
DMTSIGEP 
DMTSML 
DMTSMLF P 
DMTSTO 
DMTSTOEP 
DMTSVC 
DMTSVCEP 
DMTV EC 
DMTVECEP 
DMTV MB 
DMTVMC 
DMTWAT 
DMTWATEP 
DVASSIGN 
EBCDEC 
EBCDEC 
EBCDEC 
EBCHEX 
EBCHEX 
EBCHEX 
FILGET 
FILS ELEC 
FREEPAGE 
FREESLOT 
GENVNET 
GETBLOCK 
GETBLOCK 
GETBLOCK 
GFTLINK 
GETL INK 
GETPAGE 
GETP ARM 
GETROUTE 
GETROUTE 
GETSLOT 
GETSUPAG 
GETVRF Y 
GSUCCESS 
HDRBUILD 
HDROUT 
HEAD PREP 
HEADPREP 
HEXGET 
HEXGET 
IBLDBUFS 
INTCND 
IOERRPRT 
ISIO 
ISIO 

IS IO 
KEYWDGFT 
LINEIO 
LINEIO 
LINETIO 
LTABGET 
MAKEBLOC 
MAKEBLOC 
MAKEBLOC 
MPI 

MFO 

MSG 

MSG 

MSG 
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Ty pe 
Object,CSECT 
EP 
Object,CSECT 
EP 
Object,CSECT 
EP 
Object,CSECT 
EP 
Object,CSECT 
EP 
Object,CSECT 
Object,CSECT 
Object, CSECT 
EP 

Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
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Object 
DMTSIG 
DATSIG 
DMTSML 
DMTSML 
DMTSTO 
DMTSTO 
DMTSVC 
DMTSVC 
DMTVEC 
DMTV EC 
DATVMB 
DMT VNC 
DMTWAT 
DMTWAT 
DMTNHD 
DMT IRX 
DMTNHD 
DATNIT 
DMTIRX 
DMTNHD 
DMTNIT 
DMT CMX 
DMTA XM 
DMTCOM 
DMTA XM 
DMTIRX 
DMTNPT 
DMTVMB 
DMTVNC 
DMTAXM 
DMTCOM 
DMTCOM 
DMTIRX 
DMT AXM 
DMTCOM 
DMT AXM 
DMTCOM 
DATNPT 
DMTA XM 
DMTNHD 
DMTNHD 
DMTNPT 
DMTSML 
DMT AXM 
DMTCMX 
DATNIT 
DMTREYX 
DMTVMB 
DMTNCM 
DMT POF 
DMTSML 
DMTCMX 
DMTNPT 
DMTVMB 
DMTVMC 
DMTCMX 
DMINPT 
DMTVMB 
DMTVMC 
DMTCOM 
DMATCOM 
DMTA XM 
DMT IRX 
DMTNCM 
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MSGPROC 
MSGP ROC 
MSGPROC 


eS22eann =~ 


MSGRECV 
MSGTRANS 
MSGTRANS 
RCELINIZ 
NITINIT 
NPTERROR 
NPTGET 
NPTINIT 
NPTLINK 
NPTTERM 
OPENADEV 
OPENIN 
PACK 
PARMGET 
PARMGET 
PARMGET 
PARMGET 
PARMGET 
PARMGET 
PARMGET 
PARMGET 
POWINIT 
PUTBLOCK 


pnmTraAcYe 
FVD AVUCHN 


PUTBLOCK 
PUTVRF Y 
QUIESCE 
RCMGET 
RCMOPEN 
REORDER 
REQX EQ 
REQXKEQ 
REXCYCLE 
REXITERM 
R EXP CHEX 
RGXC MD 
RGXDOIT 
RGXMSG 
RGXYMSGER 
RGXNTHRE 
RT ABGET 
SENDEOT 
SMLINIT 
SVMRINIT 
TAGCLOSE 
TAGFIND 
T AGGEN 
TAGPLACE 
T AGSCAN 
TERMINAT 
TIMERSET 


Ty pe 

Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
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Routine 
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DM TNAD 
DMTNIT 
DMTNPT 
DMT POW 
DMTREX 
DMTSML 
DMTVMB 
DMTVMC 
DMTNCM 


DOMTNDPT 


wisest it 


DMTPOW 
DMTSML 
DMTVMB 
DETVMC 
DMT VMB 
DMTVMC 
DMT NCH 
DMTNIT 
DMTNPT 
DMTNPT 
DMTNPT 
DATNPT 
DMTNPT 
DMTNHD 
DMTAXM 
DMTVMB 
DMTCMX 
DMTIRX 
DMTNAD 
DMTNIT 
DMTNPT 
DMTPOW 
DMTSMIL 
DMTVMC 
DMT POW 
DMTNPT 
DATVMB 
DMTVMC 
DMTNPT 
DMTREX 
DMTCOM 
DMTCOM 
DMT AXM 
DMTA XM 
DMTREX 
DMTREX 
DMTREX 
DM TREX 
DMT RGX 
DMTRGX 
DMT RGX 
DMTRGX 
DMTRGX 
DMTCMX 
DMTNPT 
DMTSML 
DMTVMB 
DMTA XM 
DMTAXM 
DMTA XM 
DMT AXM 
DMTNHD 
DMTR EX 
DMTREX 
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TODEBCD 
TODE BCD 
TODEBCD 
TODEBCD 
TODEBCD 
TODE BCD 
TODEBCD 
TODS 370 
TODS 370 
TYPE 
UNPEND 
VCHANGE 
VCLOSE 
VMDEBLOK 
VMDEBLOK 
VMDEBLOK 
VMRTILT 
VMSB2CP 
VMSB2CP 
VPURGE 
VSPOOL 
VTAGD 
VTAGF 
VTAG MSG 
VTRANSFR 
XECUTE 
X ECUTE 
XECUTE 
$CRTN1 
$CRIN1 
$CRIN1 
S$IRTN1 
$MRTN1 
$PRTN1 
$PRIN1 
$PRTIN1 
$RRTN1 
$RRTN1 
$RRTN1 
$START 
$START 
$START 
$TPGET 
$TPGET 
$TPGET 
$TPPUT 
$TPPUT 
$TPPUT 
SURTNI 
$URTN1 
SURTN1 
$USREXIT 
$WRIN1 
$WRIN1 
$WRIN1 
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Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
Routine 
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DMTCMX 
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DMTNCH 
DATPOW 
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DATNPT 
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DMTA XM 
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DMTPOW 
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Section 5: Data Areas 


Data Area Aids 


This section begins with a set of graphics to help with using some of 
the pointers in SVECTORS. Details of the data in the various tables, 
blocks, and queue entries are described later in this section. 


MAINMAP LOCATION 
SVECTORS 


TABLE 


t 
MAINMAP | 
I 
l 


x*214! <--Address of main storage map 


Tl 


oe “we oun au ay <j oe ae = 


Figure 5-1. MAINMAP Location 


The main storage map pointed to by MAINMAP (Figure 5-1) has a byte for 
each page (4K) of virtual storage of the virtual machine occupied by 
RSCS. When a page is in use (allocated to or occupied by RSCS 
processor), its MAINMAP byte contains the taskid (from the task element) 
of the task that is using the storage page. (This value is X'FF' if it 
is an MSUP page.) Every unused (available) storage page has a MAINMAP 
byte value of X'00!'. 
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QUEUE ELEMENT STORAGE AREA AND FREEQ QUEUE 


SVECTORS 
TABLE 
l i 
I I 
| ! 
x*21C' | QUEUE | <--Address of first of storage reserved for 
| { queue elements 
\ I 
I | 
X'220'" | QUEUEND | <--Address of end of storage reserved for 
| | queue elements 
{ { 
| | 
X'224" {| FREEQ { <--Address of top of free queue 
I I 
4] 
I I I 
{ (first element) 
1 


address of next element—, 


(next 
element) 


amen 


ee SO ms ones 


address 


Figure 5-2. Queue Element Storage Area and FREFQ Queue 


The DMTQRQ module obtains and frees 16-byte queue elements upon request 
from an RSCS task that either reguires an element for, or is finished 
with an element in, a queue that the task maintains. 


Because of the dynamic nature of queue element management, any given 
queue's elements are not restricted to a certain contiguous and 
sequential set of elements within the queue element storage area; 
individual elements that comprise a given queue may be anywhere within 
the storage area. To support this, each queue has a "top-of-queue" 
element, pointed to by an SVECTORS entry (Figure 5-2). This element has 
a pointer to the next element in the queue, and the chaining (pointer to 
address of next) codtinues through the remaining elements of that queue, 
scattered throughout the queue storage area. 


The FREEQ queue is the set of unassigned queue elements at a given point 
in time. 


Note that this discipline applies only to queues pointed to in SVECTORS, 
and not to tables, etc. 
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SVECTORS 
TABLE 
| I 
{ | 
| | 
X'228' | TASKQ | <--Address of first task queue element (TASKE) 
| I 
(= +-—I 
! ! ! 
{ 
| (first TASKE) 
| 
> (next TASKE) 
| 
| address of next TASKE —————> —————________ 
t | 
{ | address of next TASKE 
/ | 
| | 
| I 
| address of task system save area 
————_———_—__+} 
| | 
| | 
{ 
| 
/ 
| 
| (task in RSCS storage) 
| 
Vv 


————— 
I I 

PSW | REGSAVE {| GIVE/TAKE SYNCH LOCK 

l 


Figure 5-3. Task Queue Location 


There is a task queue element for every active (started) task. This 
queue (Figure 5-3) is used by the RSCS MSUP dispatcher to start eligible 
tasks. 
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I/O QUEUE ORGANIZATION 


SVECTORS 
TABLE 
{ { 
{ { 
I { 
X'22C" | MPXIOQ | <--Address of multiplexor channel I/0 queue 
| | (points to same type structure as 
j | shown for selector channel) 
| I 
X'230" | SELIOQ | <--Address of selector channel I/O queue 
I | { 
SS 
I I { 
| | { (selector channel queue) 
! I (first active entry — lowest subchannel 
{ address with uncompleted request) 


address of next entry 


address of requesting task's I/0 table 


address (if any) of waiting (inactive) 
I/O queue entry for this subchannel 


(second selector queue entry) 
(next lowest subchannel active) 


address of next queue entry 


co! 


| 
1 
1! (next waiting (inactive) entry 
v for this subchannel) 
ee renee ete tett ee teeter Neo 


address of next entry in waiting queue 


address of requesting task's I/ table 


Figure 5-4. I/O Queue Organization 


Each I/O queue (Figure 5-4) contains only entries that are in use. All 
unused entries are in the FREEQ. Requests for I/O queue additions and 
deletions, performed by DMTQRQ in MSUP come from the IODISMIS subroutine 
in the DMTIOM module in MSUP. 
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ASYNCHRONOUS INTERRUPT QUEDE POINTERS 


SVECTORS 
TABLE 
{ I 
I I 
| | 
X*234" | IOEXITQ { <--Address of I/0 asynchronous interrupt queue 
I 
| 
I | - 
X*238* | EXTQ | <--Address of external asynchronous interrupt queue 
| ( 
I I 
| | 
X*23C* | ALERTQ | <--Address of alert asynchronous interrupt queue 
i i 
I | 
I I 


(first entry in alert queue) 


| 


address of next queue entry 


Figure 5-5. Asynchronous Interrupt Queue Pointers 


Tasks that have exit routines to process certain types of asynchronous 
interrupts must build asynchronous interrupt queve entries for their 
exit routines beforehand, by asynchronous exit requests to DATASY. The 
queue entry that DMTASY builds for each request reflects the type of 
exit condition specified in the request. 


When any asynchronous interrupt condition occurs, the asynchronous 
interrupt handler scans the appropriate queue (Figure 5-5) to see which 
task (if any) has specified an exit routine to receive control 
immediately upon occurence of an asynchronous interrupt condition of 
this type. 


A task's I/O exit routine is entered when its queue entry reflects the 
device address that has just generated an asynchronous interrupt. 


A task's external exit routine is entered when its queue entry reflects 
the bit setting of the external interrupt that just occurred. 


A task's alert exit routine is entered when it is the task that has just 
been specified in another task's alert request call to the DMTSIG 
routine in MSUP. 


For the contents of the fields in the asynchronous exit queue elements, 
see “Asynchronous Exit Queue Elements." 
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GIVE ELEMENT QUEUE LOCATION 


SVECTORS 
TABLE 
| I 
{ | 
I I 
x'2uor { GIVEQ {| <--Address of first GIVE queue element 
| | i 
SS! 
I { I 
I 
\ 
{ (top of GIVE queue) 
Vv 
cc (second) 
address of next give queve element —————> -————————_ 


address of wee 


I 
I 
1 
| 
! 
/ 
{ 
{ address of requesting task's GIVE table 
acer cama 
i of 
t of 
| | name of receiving task 
i ft 
i | 
I} 
/ 
I 
| (GIVE table in requesting task's storage area) 
V 
es ere, 
| 
I 
| 
I 


Figure 5-6. GIVE Element Queue Location 


When the requesting task issues a GIVE request, the MSUP DMTGIV module 
builds a give element in the GIVE queue (Figure 5-6), posts the 
GIVE/TAKE synch lock in the requested task, and makes the requested 
task's TASKE entry dispatchable by a call to DMTPST. 
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SVECTORS 
TABLE 
i I 
I | 
i | 
X'270" | TVECTORO{ <--Address of link table TLINKS, containing header, 
i | i followed by consecutive LINKTABL entries 
|———_+——- | 
J | | 
1 
| (number of currently active link table entries) 
| ! 
{ (initialization | (maximum allowed | 
|-defined)— {| concurrent links) | 
v I | I 
cI SY _—_V—_,+ 
i | | | 
0 } TOTAL LINKS j{ MAX LINKS {| CURRENT LINKS | 
| | I I 
ieee ena ae ee ee eee 
8 | LINKID (contains locid of this node) 
| -—_—————_—__-_-—_—__—_—_—_—_-—-—_—_—_-—- 
/ 
{|—_-—-—_—___---_-_--—_-_-__—----- 
58 | LINKID (contains linkid of first link) 
{— eae eee ss 2s ope nse ae ae Oa 
/ 
! eee itt caja ae eR 
———_—_—++ LINPUTQ | LOUTPUTQ ————————————» (see LINPUOTQ) 
| -——___--—______-----— Renee enone neteenert 
/ 
| 
A8 | LINKID (contains next link's linkid) 
| —____________-__- —____—___——_— 
| 
/ 


(queue of input tag elements, representing spool files 
to be transmitted, for this link) 


Om ee 


Pee eee 
" aaa eee 
| —-—_—_____—_-_-____-_— 

{ 


Figure 5-7. Link Table Location 


There is an eight-byte information block just ahead of the first link 
table entry. The first entry itself is a special purpose entry, 
initialized with the VM/370 system locid, for reference by RSCS. 


The LINKID field at the first of each LINKTABL block (Figure 5-7) 
identifies the link by the LOCID name of the adjacent node specified in 
the LINK statement in the dynamic directory, RSCS DIRECT, or specified 
by an operator DEFINE command. Each block contains data about one link 
(one port's line driver task). 
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ROUTE TABLE LOCATION 
SVECTORS 


TABLE 


| 
I 
I 
X*274" | TVECTOR1 <--Address of route table (TROUTE) 
| 
| 
I 


{ 
—_—_—_—_}—_ 
I 
| 
{ (Route entries. Spool files at this node with a 
| destination of locid ROUTDEST1 are forwarded on 
| link ROUTNEXT1.) 
V 
0-1 
{ J i 
| ROUTDEST1 { ROUTNEXT1 { 
{ 1 I 
10 | { 
| I I 
{ ROUTDEST2 { ROUTNEXT2 1 
| | | 
18 | I 
t | I 
{ ROUTDEST3 | ROUTNEXT3 1 
I I ! 
20 | { 
| | 


Figure 5-8. ROUTE Table Location 


The route table entries (Figure 5-8) contain the routing information 
submitted in ROUTE statements in the dynamic directory (RSCS DIRECT) or 
specified by an RSCS operator ROUTE command. 


142 IBM VM/370: RSCS Networking Logic 


Licensed Material - Property of IBM 


SWITCHABLE PORTS (TPORTS) LOCATION 
SVECTORS 


TABLE 


I 
{ 
I 
X*278" | TVECTOR2 <--Address of switchable port list, TPORTS 
| 
! 
| 


(TPORTS) 


Figure 5-9. Switchable Ports (TPORTS) Location 


The switchable port list (Figure 5-9) contains the information submitted 
in the RSCS dynamic directory (RSCS DIRECT) in PORT statements, or 
specified by the RSCS operator PORT command. 
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TAGSLOT QUEUE LOCATION 


SVECTORS 
TABLE 


| 
{ 
I 
TVECTOR3| <--Address of TAGAREA queue, TTAGQ entries, 
I 
I 
| 


x*27¢" 
I defined in TAG-FILE TAG DSECT 
—_—_—_ 

{ 

| 

| 

{ (TAG ARE A) 

v 


cc 


TAGAFREE 


I 
—_—-_+}+——________——_ 
I 
! 
I 
| 
Vv 
oe ee 
| 


{ TAGNEXT 


Figure 5-10. TAGSLOT Queue Location 


TAGAREA is a queue (Figure 5-10) of free (available) tagqslot elements. 
When they are in use, they are enqueued on the LINKTABLE of the link 
responsible for the spool file whose information is contained in the 
tagslot. 
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COMMON ROUTINE VECTOR TABLE (COMDSECT) ADDRESS 


SVECTORS 
TABLE 

{ J 

i | 

{ ( 

X"'2808 | TVECTOR4| <--Address, TCOM, of common routine vector 
{ { | table; COMDSECT 
|—-—__++——_ I 
| { | 

i 
{ 
| (COMDSECT) 
V 


oc 


Figure 5-11. Common Routine Vector Table (COMDSECT) Address 
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Data Areas and Control Blocks 


This section describes in detail the primary data areas and control 
blocks used by RSCS. Offsets are shown in hexadecimal notation at the 
right of each diagram. Following each diagram is a table that presents 
the hexadecimal offset, name, type, and description of each field. 


ASYNCHRONOUS EXIT QUEUE ELEMENT: ASYNE 


ASYNE defines symbolic addresses for elements on an asynchronous exit 
queve. An asynchronous exit queue element contains information by which 
a task requests that it handle asynchronous interrupts. 


TOEXITQ, EXTQ, and ALERTOQ in SVECTORS are the heads of three 
asynchronous exit queues. Hach of these queues comprises supervisor 
elements defined by the ASYNE DSECT. IOEXITQ points to requests for I/0 
exits, EXTQ points to requests for external exit requests, and ALERTQ 
points to requests for ALERT exits. 


We pd Be a Gg ee Oa ee eee Ee ee ee eee ON eg ee eee, ae 


0 | ASYNNEXT | 
{ I 
4G | ASYNTASK | 
| I 
8 | ASYNEXIT j 
I I 
Cc | ASYNCODE |//ASYNSPAR///| ASYNID | 
ea a nn Ee | 

0 ASYNNEXT DS 1F Address of the next asynchronous 
interrupt exit request element 

4 ASYNTASK DS  1F Address of task element describing 
the task that requested the 
asynchronous interrupt 

8 ASYNEXIT DS 1F Address of the requested asynchronous 
exit routine . 

c ASYNCODE DS AL2 Address of the device for which 
asynchronous I/0 interrupts are 
requested or interrupt bit code 

E ASYNSPAR DS 1X Reserved for IBM use 

F ASYNID DS 1X 1-byte ID of the task owning the 


asynchronous exit routine 
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DSECT 


When entering either of the read only CMS file access routines (CMSOPEN 
and CMSGET, pointed to in COMDSECT), R13 must point to a work area of 
this format. 


OPENFILE 


STATABLE 
FILENAME 
FILETYPE 
FILEDATE 
FILE WNUM 
FILERNUM 
FILEMODE 
FILEINUS 
FILELINK 
FILEFORM 


FILEFLAG 
FILEILEN 
FILESIZE 
FILE YEAR 


STATLEN 


FSTFOP 
FSTADBC 
FSTAIC 
FSTNLVL 
FSTPTRSZ 
FSTADATI 


FSTDSIZE 


* CMS Dis 


DASD 


DC 


Cc 
w 


DC 
dc 
DC 
DC 
DC 
DC 
DC 
DC 
DC 


pc 
DC 
bec 
pc 


EQU 


k Access Control Area 


DC 
pc 


OF'O',CL8* *,CL8*TEXT® 


OF'O? 
gct t 
gece et 
F'ot 
H*O? 
H'Q! 
2c" # 
HOt 
H*O? 
ci 


x'00! 
For 
H'ot 
2cr t 


*-~STATABLE 
F 

F 

F 

X11 

XL1 


CL6 
F 


(#-STATABLE) 


OF' 08 
F'ot 
AL2 (0) 
AL1(24) 
x'00! 

A (0) 
2F'Q! 
24x" 00! 


File name for OPEN request 


CMS file status table 
CMS filename 
CMS filename 
Creation date - decimal mmddhhmon 
Write item number 
Read item number 
CMS filemode 
Number of items in entire file 
CMS block number of first chain link 
File format: 
C'F' for fixed; C'vV' for variable 
File flags - always zero? 
(Maximum) length of file data items 
Number of 800-byte blocks in file 
Year of file creation (last two digits 
in EBCDIC) 
Length of CMS file status table 


Alt. file origin pointer 

Alt. number of data blocks 

Alt. item count 

Number of pointer block levels 
Length of a pointer element 

Alt. date and time (yymmddhhnmmss) 
Reserved 

File status table size in bytes 


CMS DASD I/O request table 

Synch lock 

DASD device address (set by INIT) 
Sense information required for DASD 
Device type code (set by INIT) 

Address of disk read channel progran 
Return SIO condition code and end CSW 
Return sense information on unit check 


* The values below are set by DMTINI according to the type and 
of the RSCS system disk: 


* format 


PERCYL 
PERTRACK 
OVERNUM 
DASDSECS 
DISKCLAS 


DISK BSZE 


* 
DASDREAD 
DASETS EC 
DASEARCH 


pe 
DC 
DC 
DC 
pc 
DS 
DS 
DS 


ccw 
ccw 
CCW 
CCW 
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FU0* 
Fto? 
Fro? 
20X'00# 
X'OO! 
3X 

F 

F 


X'07', BBCCHHR,CC+SILI, 6 
X'03', SECTOR,CC+SILI,1 
X'31', BBCCHHR+2,CC#SILI,5 
X'08', DASEARCH,X'00',1 


CMS records per cylinder 

CMS records per track or pair 
Record number of overlapper 
Record number - sector table 
System disk class 

Reserved 

System disk blocksize 
Reserved 


Seek (bbcchhr) 

NOP or set sector 

Search ID equal (cchhr) 
Back to search if unequal 
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DARDDATA 
BBCCHHR 
SECTOR 


CCW 
Dc 
DC 
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X'86',0,SILI, 800 Read data multi-track 
OF'O',7X'00! DASD address for reference 
x'oo8 Sector number of record above 


* Channel Program for Fixed Block Architecture Devices 


CFBAREAD 
FBACCWD2 


PBACCWX 2 
FBAD2A 


FBAD2ALB 


FBAL2A 


FBAL 2ANB 
FBAL2ABO 
VOLCCHS 


VOLCCW1 


NEXTLINK 
LINK END 

LINKLIST 
EDFOV BUF 


NEXT BLOK 
BLOKEND 
BLOKLIST 


NEXTITEM 
ITEMEND 
FILCHBUF 


CFILSAVE 
COPNSAVE 
CGETSAVE 


ENXTITEM 
MVLEN 

NXTRECPT 
DABLKCNT 


APTRBLK 
AEDFBUF 


ADTIDENT 
ADTID 
ADTVER 
ADTDBSIZ 
ADTDOP 
ADTC YL 
ADTMCYL 


DC 
ccw 
ccWw 
ccw 
DS 
DS 
DS 
DS 
DS 


DS 
DS 
DS 
DS 
DS 
DS 
CCW 
CCW 
ccw 
CCW 


DC 
pc 
DC 
DS 
EQU 


DC 
DC 
pc 
DS 


DC 
Dc 
DC 
DS 


DS 
DS 
DS 


DS 
DS 
DS 
DS 


DS 
DS 


DS 
DS 
DS 
DS 
DS 
DS 
DS 
DS 


ODO? 

X¥"'63",FBAD2A,CC+SILI,16 Define extent 
X¥'43', FBAL2A,CC+#SILI,8 Define extent 
X¥*42*,0, SILI, 80 Define extent 
x'4o' Mask (Inhibit Write) 
X*000000! Reserved 

Fto? Extent offset 

Ftgoe First block offset 
FF" Last block offset 
OF Locate list 

x'O6! Operation (Read) 
x'oo' Aux byte 

H' 18 Number of blocks 
rq? Block offset 

OD 


X¥'07',0,CC+SILI,6 
X'31',0,CC+SILI,5 
X¥'08',*-8,0,0 
X'06',0, SILI, 80 


ODO! 

A (0) Address of pointer to next chain link 

A (LINKLIST+ 80) End of chain link list 

80C List of CMS chain link block numbers 

LINKLIST This 80-byte area is used for an 
overflow buffer when the system disk 
is EDF format 

Op'o? 

A (0) Address of pointer to next data block 

A(BLOKLIST+120) End of current data block list 

800C List of CMS file data block numbers 

OD'o8 

A(0) Address of next (unread) data item 

A (FILCHBUF+800) End of FILCH data buffer 

800C Buffer for CMS block FILCH routine 

8F Save area for CMS FILCH routine 

oF Save area FOR CMS OPEN routine 

oF Save area FOR CMS GET routine 

F'or Absolute value of next (unread) data item 

Fo? Move length when record spans two blocks 

For Address of next record in buffer 

rig Number of blocks processed 

A Address of EDF pointer block 

A Address of EDF data block 

OF Allign 

CL4 Volume/label identifier 

C16 Volume start / volume identifier 

CL2 Version level 

F Disk block size 

F Disk origin pointer 

F Number of formatted cylinders on disk 

F Maximum number of formatted cylinders 
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ADTNUM 
ADTUSED 
ADTFSTSZ 
ADTNFST 
ADTCRED 


ADTLABSZ 
ADTDKFOR 
ADTDVTYP 


CMSACCL 


Material - Property of IBM 


on disk 
DS F Disk size in blocks 
DS F Number of disk blocks in use 
DS F Size of file status table 
DS FP Number of file status tables per block 
DS CL6 Disk creation date (yymmddhhmmss) 
DS C1L30 Reserved 
EQU) *-ADTIDENT Length of label 
DS F 
F 


EQU) ((*-CMSACCES) +7} /8 Number of double words in CMS Access 


area 
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COMDSECT TABLE CONTENTS 


The COMDSECT table contains pointers to common supervisor routines. 


150 


10 
14 
18 
1c 


20 


28 


a Sg a Oey ee pene eae Oe met ge NR eg eee Og ee ee ae 


| GLINKREQ | 

| | 

| GROUTREQ | 

{ I 

| GPAGEREQ | 

l I 

I FP PAGEREQ | 

I I 

| PMSGREQ | 

| | 

| GMSGREQ | 

| I 

i GTODEBCD { 

I I 

{ GTODS370 { 

| I 

| CMSOPEN | 

| | 

! CMS GET | 

I I 

| GPAGESUP { 
nna nnn es | 
0 GLINKREQ DS 1A Get link table entry routine 

4 GROUTREQ DS 1A Get routing table entry routine 
8 GPAGEREC DS 1A Get page of main storage 

Cc FPAGEREQ DS 1A Free page of main storage 
10 PMSGREQ DS 1A Put message element into message stack 
14 GM SGREQ DS 1A Remove message element from message stack 
18 GTODEBCD DS 1A Convert S/370 TOD* to EBCDIC TOD 
1c GTODS370 DS 1A Convert EBCDIC TOD to S/370 TOD 
20 CMSOPEN DS 1A Open CMS file** 
24 CM SGET DS 1A Read next record of CMS file** 
28 GPAGESUP DS 1A Allocate a page of virtual storage for 


supervisor use 


* Time-Of-Day 
** See CMS File Access Work Area 
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2 rorrr 
z ruNLiL 


ay 


FREEE defines an element in the chain of elements that comprise the free 
element queue. 


FREEQ in SVECTORS points to the chain of free elements, each of which is 
defined by the FREEE DSECT. 


Sy a a ee ie Te eS ee a ee ee ee 


0 | FREENEXT | 
i I 
4 | FREESPAR | 
| I 
8 | I 
{ SS 
c | | FREEID | 
| | 
0 FREENEXT DS 1F Address of next element in free queue 
uf) FREESPAR DS CL11 Spare field 
F FREEID DS 1X Standard taskid offset 


(x'00" denotes free element) 


GIVE QUEUE ELEMENT: GIVEE 


GIVEE defines symbolic addresses for items used in processing a GIVE 
request. 


GIVEQ in SVECTORS points to the queue of GIVE elements used in task-to- 
task communications. 


The GIVEADDR field of this DSECT is the address of a GIVE request table, 
which, in turn, contains addresses of buffers for elements describing 
requests and responses to requests. These tables are described below; 
the elements that fill the buffers are described in "Request Elements". 


Ce ei ere OER cong pe es Meh eee eee Ee Le eT ee ee ag a pe ap ee gy ore ae 





0. | GIVENEXT I 
| | 
4 {| GIVEADDR { 
l | 
8 | GIVENAME | 
I | 
Cc | GIVESPAR | GIVENID | GIVERID l 
| en | 
0 GIVENEXT DS 1F Address of next GIVE element 
4 GIVEADDR Ds 1F Address of GIVE request table in 
sending task's storage 
8 GIVENAME DS CL4 Task name of receiving task 
Cc GIVESPAR DS AL2 Unused 
E GIVENID DS 1X 1-byte ID or receiving task after TAKE 
F GIVERID DS 1x 1-byte ID or sending task 
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GIVE REQUEST TABLE IN GIVE/TAKE REQUESTING TASK 


The format of a GIVE Request Table is: 


(Ge ee ee Neg ee EE TS Se See eg ee wpe, ee 


0 | synch lock | 
4 task name or A(GIVE Element) 
8 A(GIVE Request Buffer) 
Cc A(GIVE Response Buffer) 


ee en ve ee | 


When a task requests the services of another task via a GIVE request, 
the second field of the table above contains the task name of the task 
to which the task is to be sent. When DMTGIV builds a GIVE element for 
the request, it overlays this task name with the address of the GIVE 
element. 


The task performing the requested service builds a table called the TAKE 
request table, which corresponds to the GIVE request table. 
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a 


I/O REQUEST QUEUE ELERENT: IOE 


IOE defines symbolic addresses of elements and other information 
associated with an I/0 operation requested by a task. 


MPXIOQ and SELIOQ in SVECTORS point to queues of I/O elements for the 
multiplexer and selector channels, respectively. 


The IOTABLEA field points to the address of an I/O table defined by 
IOTABLE, which is described in this section. 


eg a ee ee Ae ee ge ee a ee ee Oe 


oO | IONEXT | 
4 IOSUBQ 
8 IOTABLEA | 
Cc IOADDR {| IOSBCHAN | ION 


nr NN | 


0 IONEXT DS 1F Address of next active I/0 element 
4 IOSUBQ DS 1F Address of next inactive I/O element 
for a given subchannel 
IOSTAT EQU * Status flags for current I/O operation 


(First byte of IOTABLEA) 


Bits defined in IOSTAT 





SENSING FQU) x'80* Flag set to 1 while automatic 
sense is active 
CHANDONE EQU x40" Flag set to 1 when subchannel terminates 


8 IOTABLEA DS 1F Address of I/O request table in task storage 
Cc IOADDR DS AL2 Address (cuu) of the device requesting 
current I/0 operation 
E IOSBCHAN ODS 1X Subchannel address; 1-byte; 
assigned by MSUP 
F IOID DS {Xx ID of task associated with this 


I/O operation; 1-byte; assigned by MSUP 
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I/O REQUEST TABLE IN REQUESTING TASK: IOTABLE 


The I/O request takle contains data used in processing an I/O request. 
The first five fields are filled in by the task to convey information 
about the I/O request to the supervisor. The last three fields are 
filled in by the supervisor to convey status information about the I/0 
operation to the task. 


Ca ae ON es eet ee ge ye ee ee eee 


0 | IOSYNCH I 
{ { 
4 {| DEVCUU I SENSREQ DEVCODE | 
I { 
8 | PROGADDR I 
{ { 
c | ENDCSW | 
{ { 
10 | | 
{ Be Se 
14 | ENDSENSE 1 
{ ns | 
0 IOSYNCH DS IF Synchronization lock for I/O operation 
4 DE VCUU DS AL2 Address (cuu) of device associated with this 
I/O operation 
6 SENSREQ DS AL! Number of sense bytes requested on unit check 
7 DEVCODE DS AL1 1-byte V¥M/370 device type code (not used by 
I/O manager) 
8 PROGADDR DS 1F Address of channel program for the I/0 
operation 
SIOCOND EQU * 1-byte SIO condition code return information 
Cc ENDCSW DS 2F Ending CSW with composite status return 
information 
14 ENDSENSE DS AL1 Requested return sense information on unit 


check CSW status 


TYPPUN EQU x'80* vM/370 type code for the punch 
TYPPRT EQU X*40" VM/370 type code for the printer 
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LINK TABLE ENTRY: 


LINKTABL 


LINKTABL describes the status of a single link in the network; 


collectively, all the links defined for the system are referred to as 


the link table. 


The first link table entry has the locid of this RSCS node in the linkid 


field. Normal link definitions start in the second link table entry. 
SSS ee 
0 | LINKID I 
i { 
4 | { 
— { 
8 | LDEF TNME I 
I I 
c | LAC TTNME ! 
I { 
10 | LDEFDRVR | 
| I 
14 j i 
I 1 
18 | LAC TDRVR | 
I { 
1c | ! 
| { 
20 | LDEFLINE 1 LACTLINE | 
| | 
24 | LDRVRVAR | 
I I 
28 | LDEFCLS1 [| LDEFCLS2 | LDEFCLS3 | LDEFCLS4 | 
I I 
2C | LACTCLS1 {| LACTCLS2 } LACTCLS3 | LACTCLS4 | 
{ { 
30 | LTIMEZON | LSPARE | LFLAG I 
I | 
34 LTIMER ! 
| | 
38 | LINPUTQ 1 
t | 
3c | LOUTPUTQ 1 
I I 
40 | LWORKQ I 
I | 
aq | LRESERVD | LPENDI NG ] 
| | 
48 | LTAKEN | LTRNSCNT I 
I | 
4c | LERRCNT | LTOCNT ] 
ea ea ere ee a an TSS eee ee een ae 
0 LINKID DS CL8 EBCDIC linkid 
8 LDEFTNME DS CL4 Default task name 
Cc LACTTNME ODS CL4 Active task name 
10 LDEFDRVR ODS CL8 Default driver id 
18 LACTDRVR ODS CL8 Active driver id 
20 LDEFLINE DS 2X Default virtual line address 
22 LACTLINE DS 2X Active virtual line address 
24 LDRVRVAR ODS 1F Line driver variable information 
28 LDEFCLS1 DS CcL1 Default spool file class 1 
29 LDEFCLS2 DS CL1 Default spool file class 2 
2A LDEFCLS3 DS cL1 Default spool file class 3 
2B LDEFCLS4 ODS CL1 Default spool file class 4 
2C LACTCLS1 DS CL1 Active spool file class 1 
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2D LACTCLS2 ODS CcL1 Active spool file class 2 

2E LACTCLS3 DS cL1 Active spool file class 3 

2F LACTCLS& DS CL 1 Active spool file class 4 

30 LTIMEZON DS 1X Time zone displacement west from GMT 
31 LSPARE DS 1X Spare byte 

32 LF LAG DS 2X Link table status flag bytes 


Bits defined in LFLAG 


LACTIVE EQU§ xX'80* Link active (line driver task loaded) 


LALERT FOU x'GO' AXS ALERT exit set 
LHOLD EQU xX'20" Link hold set 
LDRAIN EQU} xX*10' Link drain in progress 


LCONNECT EQU x'08* Link connected 
LTIMERON EQU) xX'02* Timer ALERT request outstanding 


LHALT EQU xX'O1" Link to be forced inactive 
34 LTIMER DS 1F Active task timer value 
38 LINPUTO DS 1F Input file tag queue address 
3c LOUTPUTQ DS 1F Output file tag queue address 
40 LWORKQ DS 1F General string stack address 
Gu LRESERVD ODS 1H Count of tag elements reserved 
46 LPENDING DS 1H Count of unaccepted tags 
48 LTAKEN DS 8X Count of tag slots in use 
OA LTRNSCNT DS 1H Link transaction count 
4c LERRCNT DS 1H Error Count 
4E LTOCNT DS 1H Timeout count 


LINKLEN EQU) ¥*-LINKTABL Length of link table entry 


An 8-byte header precedes the first entry in the link table (that is, 
the first link defined by the LINKTABL DSECT). The TLINKS field 
(TVECTORO) in SVECTORS points to this header: 





0 4 6 
fot a ae eee a 6S Se Se aa ifs aoe ee Se | SO ee a ee ee ee 
| Total links I max | current | 
I | links | links | 
ne ee ee edd 
where: 
total links is the total number of link table entries generated 
during RSCS initialization. 
max links is the maximum number of concurrently active links 


allowable. 


current links is the number of links active in RSCS at a given time. 
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The MLX records are created by VSE/POWER. 


various characteristics of the output file. 


ML 


Record 1: 
0 
| MLX1HDR i 
8 | ! 
| MLX1HDR (CONT.) | MLX1 JNME I 
10 | | 
{ MLX1JME (CONT.) t <3 Al MLX1USER | 
18 | { 
| MLX1USER | 
20 «| i 
{ MLX1USER | r 4 JNUM | 
28 i 
{| JNOM(CONT)} , | QID | , | MLXIDTYP | , ! 
30 | | 
| gcL | ; {| JPR | el MXL1TRNOM | 
38s ———-| 
| MLXIRNOM (CONT.) | , i MLX1JSF_ | e | 
4o I { 
| MLX1COP | | 
4g ne ee eee eee ee ed 
MLX1HDR DS CL12 MLX RECORD 1 HEADER: * $$ MLX Q1I= 
MLX1JNME DS CL8 JOB NAME 
DS CcL1 , DELIMITER 
MLX1USER DS CL16 USER INFORMATION 
DS CL 1 DELIMITER 
MLX1JNUM DS XL4 JOB NUMBER 
DS CL 1 , DELIMITER 
MLX1QID DS Cc QUEUE RECCRD ID 
DS cL1 , DELIMITER 
MLXIDTYP DS XL2 DEVICE TYPE OR LINE ID 
DS CL1 , DELIMITER 
MLX1JCL DS cL1 JOB CLASS 
DS cL1 ,DELIMITER 
MLX1JPR DS CL1 JOB PRIORITY 
DS CL1 , DELIMITER 
MLXTRNUM DS XL8 RECORD COUNT 
Ds CL1 »DELIMITEP 
MLX1JSF DS XL2 JOB SUFFIX NUMBER 
DS CL1 , DELIMITER 
MLX1COP DS XL2 NUMBER OF COPIES 
MLX1LEN EQU *-MLX TREC LENGTH OF MLX RECORD 1 
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0 Tet ware pg Oe Sea oP tree yet gre a eo me Poe ee ala Nae Se hPa 7% 
| MLX2HDR | 
8 (PSS eee ee re ee a ee ee { 
| MLX2HDR (CONT. ) | MXL2PNUM | 
10 jee ees SS SS ee a SS 
| ’ } DSP |{ , 1 MLX2SEP | , | MLX2CTAB | 
18 | ------- $$ - - - - - - - - -- - - --- + --- --- | 
{ MLX2CTAB |[{ , | MLX 2FOID | 
20 SSeS SSS SaaS es SSS ee Sse ee SSS | 
| MLX2FOID (CONT) | ’ | MLX 2CGRP ] 
28 [eS ses So Sas oa SS aS ea = 5 SS S55 SS -== | 
i] MLX2CGRP (CONT.) | 
30 aa aa akc a | 
I MLX2CGRP (CONT. ) 1 ’ { MLX2PST 1 e { 
38 [S335 6s HSS e858 S838 SSeS es Ses Sasa ese == | 
{ MLX2 0PT I ’ | MLX2RID 1 { 
4ao baw a wn a ne a Jj 
QO MLX2HDR ODS CL12 MLX RECORD 2 HEADER: * $$ MLX Q2= 
C MLKZPNUM DS XL4& NUMBER OF PAGES 
10 DS cL1 , DELIMITER 
11 MLX2DSP DS CL1 DIS POSITION 
12 DS cL1 , DELIMITER 
13. MLX2SEP ODS XL2 NUMBER OF SEPARATORS 
15 DS cCL1 , DELIMITER 
16 MLX2CTAB DS CL4 COMPACTION TABLE NAME 
1A DS CL 1 , DELIMITER 
1B MLX2FOID DS XL8 FORMS OVERLAY ID - 3800 
23 DS CcL1 7, DELIMITER 
24 $MLX2CGRP DS XL16 COPY GROUPS - 3800 
34 DS CL1 ,» DELIMITER 
35 MLX2PST DS XL2 PAPER STATUS - 3800 
37 DS CL 1 DELIMITER 
38 MLX20PT DS XL2 OPTION BYTE - 3800 
40 DS CL1 e DELIMITER 
41 MLX2RID DS XL2 ORIGIN REMOTE ID FOR LIST/PUNCH 
42 MLX2LEN EQU *—MLX2REC LENGTH OF MLX RECORD 2 
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MLX Record 3: 


0 SSS a er 
| MLX 3HDR i 
8 i 
| MLX3HDR (CONT.) | MLX 3CNUM | 
10 { i 
{ MLX3CNUM (CONT. ) 1 -f | MLX3FMID | 
18 | I 
1 1 | 
20 | Sn nO See 
QO MLX3HDR ODS CL12 MLX RECORD 3 HEADER: * $$ MLX Q3= 
C MLX3CNUM DS XL8 LINE OR CARD COUNT 
13 DS CL1 e DELIMITER 
14 MLX3FMID DS CLY FORMS IDENTIFIER 
MLX3LEN EQU *_MLX3 REC LENGTH OF MLX RECORD 3 
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NETWORK ACCOUNTING CARD FORMAT 


160 


(oe we ee ee ee ee Fn ee ee ee ee ee ee 


oO | (Local Network Userid) | 
4 | I 
I 1 
8 | ACNTUSER ! 
Cc | I 
| | 
10 | ACNTDATE I 
14 | { 
18 | I 
| | 
1c | ACNTOID { ACNTID 1 
| ! 
20 | ACNTILOC { 
24 | { 
I { 
28 | ACNTDEST 1 
2c | I 
{ { 
30 | ACNTCLAS | ACNTINDV | /(/S/S/S/S/S¢S¢ 44444 
l I 
34 | ACNTRECS { 
| I 
38 | ACNTTOVM I 
3c | ! 
I i 
ROL SPSL LAL SS ALI LLL I LF TS LITO SIF 
HH E SSS SS SSSSSSSSSSASASSLSSASISSS 
I | 
4B | ACNTSYS I 
t I 
4c | | ACNTCODE | (Record ID) I 
nn er nell 
DS cL8 1-8 Local network USERID fixed by CP 
ACNTUSER DS CL8 9-16 Originating location USERID 


ACNTDATA DS CL12 17-28 Date and time of record (MMDDYYHHMMSS) 
ACNTOID DS CL2 29-30 Origin spool file ID 


ACNTID DS CL2 31-31 Local spool file ID 

ACNTILOC DS CL8 33-40 Originating location ID 

ACNTDEST DS CL8 41-48 Destination location ID 

ACNTCLAS DS CL1 49 Class 

ACNTINDVY DS CL 1 50 Origin device type ('8N'=PUN/'4N'=PRT) 


Ds CL2 51-52 Filler 
ACNTRECS DS CL4 53-56 Number of records in file 


ACNTTOVM DS CL8 57-64 Destination location USERID 
DS CL8 65-72 Filler 

ACNTSYS DS CL5 73-77 System ID (Serial + Model) 

ACNTCODE DS CL 1 78 Transmission code (01=SEND/02=RECYV) 
DS CL2 79-80 Record identifier ('C0O') fixed by CP 
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DRABM M2 anrtn 
rcvansd 4A DLE 


BUILT BY: DMTIRX at RSCS initialization 


FUNCTION: Record allocation status of switchable line ports 
available to RSCS 


DESCRIPTION: The first doubleword of the table is reserved for control 
information. Each following halfword contains the 
virtual device address of a line port which may be 
dialed, and which is available to RSCS. 


Cn a ee ee ee ey pe a ee 





0 | Number of Line Port Entries | 
| in Table ! 

I I 

4 | { 
I I 

! i a eens | 

8 | Virtual Line Address I Virtual Line Address | 
I ! I 

I | 

Cc | Virtual Line Address i] Virtual Line Address | 
| | ! 

| 1 
10 | | | 
| | 

| Virtual Line Address | Virtual Line Address | 

{ | 


OPERATIONAL NOTES: The line port entries are marked "in use" by setting 
the high-order four bits of such entries to 1s. 
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ROUTING TABLE ENTRY 


Ge ge I a ge ee age a ee 


ROUTDEST 


ROUTNEXT 


QO ROUTDEST DS C18 Final destination ID 
8 ROUTNEXT DS CL8 LINKID for inderect routing 


The routing table contains routing information as submitted either in 
the operator ROUTE commands or in the RSCS DIRECT ROUTE entries. The 
SVECTORS field TVECTOR1 contains TROUTF, the address of the ROUTE table. 
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SPOOL PAGE BUFFER FORMAT 


| 


One 

Page 
(4096 
Bytes) 


<j ae ee 





0 I | 
l | 
| ¥4/370 Spool Control Information | 
8 | | 
I i 
4 I4 
10 | NOP CCW 1 | 
! 14 
{ | | TAG Record 
18 | TIC CCW 11 (in First 
| | > Page Buffer 
1 [| | of Each 
20 | 1 | Spool File) 
/ TAG Data: 136 (X'88"') Bytes / | 
I 14 
A8 | | 
| / 
/ Subsequent Spool File Records | 
I I 
a 4 X' FFF 


When an output file is first spooled to RSCS from a virtual machine user 
on the same VM/370 system, the tag data is set according to the user 
specification in the TAG command to CP. 


When an RSCS line driver 
(to itself) in an output 


in the tag 


forward ('S&F*') flag. 


record. This RSCS—-built tag data includes a store-and- 
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TELECOMMUNICATIONS BUFFER 


164 


Neo 


OQ pwon~) 


Ra a aR aa a OI | 


0 | BUFCHAIN [ 
{ ( 
4H | BUFCOUNT | BOFSTAT 4} BUFSTART | 
I { 
8 | {| BOFBCB { BUFFCS | 
{ | 
c | BUFDATA " 
| | 
/ / 
| { 


BUFDSECT DSECT 

BUFBEGIN DS OF Beginning of the buffer 
BUFCHAIN DC A(0) Buffer chain field 
BUFCOUNT DS 1H Count of bytes to transmit 
BUFSTAT DS 1C Buffer status byte 


Bits defined in BUFSTAT 

BUFFAKE EQU X'01' Dummy buffer indicator 

BUFRESP EQU X*'02' Response only in buffer 

BUFNAK EQU X'O4* NAK response (negative acknowledgement) 
being sent 

BOFTEXT EQU X*'08' Buffer contains text information 

BUFUCHEK EQU X'10' Unit check expected 


BUFSTART DS CL2 Transmission control bytes 
BUFBCB DS 1C Block control byte 

BUFFCS DS CL2 Function control sequence 
BUFDATA DS OF Data portion of buffer 
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SVECTORS: LOW STORAGE DEFINITIONS 


SVECTORS defines low storage for the RSCS virtual machine. 
It includes two types of storage: machine-defined and RSCS-defined. 


Machine-Defined Low Storag 





The SVECTORS machine-defined lov storage defines machine status 
data referenced during program execution and required by Systen/370 
architecture. 
SSS SS ee 
0 | IPLPSW I 4O | cswW H 
4 | l 44 | | 
| j I I 
8 | IPLCCW1 | at Na ie te 
cH i GC j (unused) { 
l | I I 
10 | IPLCCW2 | 50 {_ che 8) eee! | 
14 | i 54 | (unused) { 
I I | I 
18 | OLDEXT ] 58 | NEWEXT { 
1c {| l SC | I 
t I | | 
20 | OLDSVC | 60 | NEWSVC I 
24 | { 64 | | 
| I 1 I 
28 | OLDPROG I 68 | NEWPROG { 
2c | I 6c | I 
l | | 1 
30 | OLDMACH | 70 | NEWMACH { 
34 | | 74 | | 
! ! I hae omemo ioe: i 
38 | OLDIO { 78 { NEWIO | 
3c | 1 7c l 
= | 


0 IPLPSW DS D x'000400008 V (DMTINT) 
8 IPLCCW1 DS D 
10 IPLCCW2 DS OD 
18 OLDEXT DS OD External interrupt old PSW 
20 OLDSVC DS D Supervisor call old PSW 
28 OLDPROG DS D Program check old PSW 
30 OLDMACH DS D Machine check old PSW 
38 OLDIO DS OD Input/output old PSW 
40 cswW DS OD Channel status word 
48 CAW DS OD Channel address word 
4C DS F Unused 
50 TIMER DS F 4X'FF* 
54 DS F Unused 
58 NEWEXT DS D x*00040000! V (DMTEXT) 
60 NEWSVC DS D xX'00040000!5 V (DNTSVC) 
68 NEWPROG DS D xX*'000400008 V (RE XOUCH) 
70 NEWMACH DS D X*00020000! A(OLDMACRH) 
78 NEWIO DS D x'90040000! V(DMTIOMIN) 
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SVECTORS Table Contents 


—————— 





RSCS program storage begins with the SVECTORS table at hex location 200 
in supervisor module DMTVEC. The SVECTORS table contains pointers to 
modules that comprise the supervisor, to supervisor control queues, and 
to queues of requests for supervisor services. 


re kr, a ee ied pe eee 


200 | NEWPSW { 
I I 
208 | SSAVE | 
| i 
210 | ACTIVE | MAINMAP i 
I I 
218 | MAINSIZE { QUEUE | 
1 1 
220 | QUEUEND { FREEQ | 
| | 
228 | TASKQ I MPXIOQ | 
| I 
230 | SELICQ { IOEXITQ { 
I I 
238 | EXTQ | ALERTQ { 
| | 
240 | GIVEQ | QREQ { 
l 1 
248 j DISPATCH I WAITREQ | 
I I 
250 | POSTREQ 1 IOREQ { 
I | 
258 | TASKREQ 1 MAINREQ { 
I l 
260 | AS YNREQ 1 ALFERTREQ | 
I l 
268 | GIVEREQ | TAKEREQ 1 
I ! 
270 | TVECTORO | TVECTOR1 1 
l | 
278 | TVECTOR2 | TVECTOR3 { 
I | 
280 | TVECTOR4 { TVECTORS { 
I | 
288 | TVECTOR6 | TVECTOR7 | 
I \ 
290 | | 
l Reserved I 
1 { 
{ | 
2A0 | | 
/ COPYRIGHT STMT / 
| | 
I SS SS 
2E8 | { Reserved 1 
i I 
2F0 | { 
/ SYSTEM PATCH AREA / 
368 | | 
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aan Pek +h Yalta 


ORG SVECTORS+xXK*200 


200 NEWPSW DC p'or 

208 SSAVE DC _-2F 0" 

210 ACTIVE pc —_- x": 00 
DC —_ AL3 (0) 


214 MAINMAP DC A(0) 


218 MAINSIZE DC F*O? 

21¢c QUEUE pe A(0) 

220 QUEUEND DC a(0) 

224 FREEQ pc A(0) 

228 TASKQ pc a((0) 

22C MPXIOQ pce A(0) 

230 SELIOQ DC —A(0) 

234 IOEXITQ DC A(0) 

238 EXTQ pc a0) 

23¢ ALERTQ pc a0) 

240 GIVEQ pC A(0) 

244 QREQ DC =—- V (DMTORQ) 

248 DISPATCH DC V(DMTDSP) 

24c WAITREQ DC V(DMTWAT) 

250 POSTREQ DC V(DNTPST) 

254 IOREQ DC V(DMTIOMRQ) 

258 TASKREQ DC  V(DMTASR) 

25C MAINREQ DC  V(DMTSTO) 

260 ASYNREQ DC  V(DMTASY) 

264 ALERTREQ DC A(DMTSIG) 

268 GIVEREQ DC  V(DMTGIV) 

26C TAKEREQ DC  V(DMTAKE) 

270 TVECTORO DC A(0) 

274 TVECTOR1 DC A(0) 

278 TVECTOR2 DC A(0) 

27C TVECTOR3 DC A(0) 

280 TVECTOR4 DC A(0) 

284 TVECTORS DC A(0) 

288 TVECTOR6 DC A(0) 

28C TVECTOR7 DC A(O0) 
TLINKS EQU TVECTORO 
TROUTE EQU TVECTOR1 
TPORTS EQU TVECTOR2 
TTAGQ EQU TVECTOR3 
TCOM EQU TVECTORG 


Leave room for machine extensions 
Dispatched PSW for last dispatcher 
General—purpose low storage save 
area 

ID of currently active task 
Address of task element for last 
dispatchee 

Address of start of main storage 
allocation map 

Total number of pages in main 
storage 

Address of start of supervisor 
queue 

Address of end of last supervisor 
queue element 

Address of start of free element 
queue 

Address of start of task elerenmt 
que ue 

Address of start of multiplexer 
I/O queue 

Address of start of selector I/0 
que ue 

Address of start of asynchronous 
I/O request element queue 
Address of start of external 
request element queue 

Address of start of task 
asynchronous request element queue 
Address of start of GIVE request 
element queue 

Supervisor queue allocation 
request entry address 

Task dispatcher entry address 
Wait request entry address 

Post request entry address 

I/O request entry address 

Task management request entry 
address 

Main allocation request entry 
address 

Asynchronous interrupt request 
entry address 

Task asynchronous signal request 
A(ALERT) entry address 

Task request GIVE request 

entry address 

Task request TAKE reguest 

entry address 


Task defined field 
Task defined field 
Task defined field 
Task defined field 
Task defined field 
Task defined field 
Task defined field 
Task defined field 


Link table address 

Route table address 
Switchable port table address 
Tag slot queue 

Common routine chain 
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TVMID 


COPYRITE 


CSTATEND 


SYSPATCH 


EQO 


DS 
FOU 
DC 
DC 
EQU 
DC 
DS 
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TVECTORS Pointer to local host virtual 
machine user id 

uF 

* Copyright statement 


C'*5748-xP1 COPYRIGHT IBM CORP 1979 * 


C'LICENSED MATERIAL—PROGRAM PROPERTY OF IBM! 
* 


CL6' ° Reser ved 
128X ** System Patch Area ** 
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TAG QUEUE DATA: TAGAREA 


TAGAREA in DMTAXS module contains data about the disposition of the tag 
queue element pointers and other tag control information. It is pointed 
to by TTAGQ in SVECTORS. 


Go ae Sn RE NY et Oe eg ee ee Pato eet, eee Tees Be ay = a 


oO | TAGAFREE | 
i 1 
& | TAGACIN { 
I I 
8 | TAGACOUT ! 
i—— I 
Cc f TAGAGOT { TAGAHOLD | 
a a es ee 
0 TAGAFREE DC A(Q) Address of queue of free TAG slots 
(or elements) 

4 TAGACIN pc A(0) Pointer to queue of active input TAGs 
8 TAGACOUT DC A(0) Pointer to queue of active output 
TAGS 
Cc TAGAGOT Dc HfOo? Number free slots left 
E TAGAHOLD DC #H*0O! Number slots to be held 
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TAG QUEUE ELEMENT FOR RSCS SPOOL FILE 


TAG describes a file enqueued for processing by RSCS. Part of the data 
in this area is built from tag data specified via the CP TAG command and 
inserted by CP into the spool file block (SFB) at the start of the spool 
file. RSCS reads the SFB and copies the appropriate data into the tag 
slot that it constructs for this file. Each tag slot entry in use is 
enqueued on the input (for transmission) or output (while receiving) 
queue of the line driver task responsible for the file. 


CON a ee Pp a FON ee ine ag a GY eg eae ee ae 


01 TAGNEXT I 
I | 

4 | TAGBLOCK l 
1 { 

8 | TAGINLOC { 
| | 

c | i 
{ 1 

10 | TAGLINK 1 
{ 1 

14 | 1 
i I 

18 | TAGINTOD I 
l ! 

1c | I 
| I 

20 | TAGINVM { 
i I 

24 | \ 
I | 

28 | TAGRECNM { 
1 l 

2c | TAGRECLN | TAGINDEV | TAGCLASS | 
1 { 

30 | TAGID 1 TAGCOPY 1 
| | 

34 | TAGFLAG | TAGFLAG2 {| TAGORGID { 
! 1 

38 | TAGNAME { 
/ / 

I { 

uy | TAG TYPE t 
/ / 

I I 

50 | TAGDIST I 
I { 

54 | I 
I | 

58 | TAGTOLOC | 
I 1 

5c | { 
| { 

60 | TAGTOVM { 
[ I 

64 | { 
1 I 

68 | TAGPRIOR 1 TAGDEV { 
I I 

6C | TAGCNTRL { 
l { 

70 | TAGRECLT 1 TAGSPARE I 
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TAGNEXT 
TAGBLOCK 
TAGINLOC 
TAGLINK 
TAGINTOD 
TAGINVM 
TAGRECNM 
TAGRECLN 
TAGINDEV 
TAGCLASS 
TAGID 
TAGCOPY 
TAGF LAG 
TAGFLAG2 
TAGORGID 
TAGNAME 
TAGTYPE 
TAGDIST 
TAGTOLOC 
TAGTOVA 
TAGPRIOR 
TAGDEV 
TAGCNIRL 
TAGRECLT 
TAGSPARE 


TAGLEN 


Section 5: 


EQU *-TAGNEXT 


Address of next active queue entry 
Address of associated I/O area 
Originating location 

Next Location for transmission 

Time of file origin 

Originating virtual machine 

Number of records in file 

Maximum file data record length 
Device code of originating device 
File output class 

Current VM/370 Spool ID 

Number of copies required 

VM/370 SFBLOK control flags (SFBFLAG) 
VM/370 SFBLOK control flags (SFBFLAG) 
VM/370 Spool ID at origin location 
Filename 

Filetype 

File distribution code 

Destination location ID 

Destination virtual machine ID 
Transmission priority 

Active file's virtual device address 
Network Control record format 
Number of records left in file 

Spare Fullword 


Length (in bytes) of the file TAG 
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TAKE REQUEST TABLE IN GIVE/TAKE REQUESTED TASK 


The format of a TAKE request table is: 


Ry ee pe ee a re a a es ee ee ee Ge 


Oo |} Task name of GIVE requestor | 
i | 
4 {| A(TAKE Request Buffer) { 
! | 
8 | A(TAKE Response Buffer) I 


eae nan en nS ee | 
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TANKS 


Unit Record Tank 


Ce ge ee a ae ee ea Oe ep gg ee ee oe aes eee 





0 { TANKCHN I 
I l 
4 | TANKRCB i TANKSRCB | TANKCNT | 
I I 
8 | TANKDATA { 
i i 
/ / 
{ { 
NN eee 
TANKDSEC DSECT 
0 TANKCHN DC A (0) Beginning of the buffer 
4 TANKRCB DS 1c Tank record control byte 
5 TANKSRCB ODS 1c Tank sub-record control byte 
6 TANKCNT DS 1H Count of data bytes in tank 
8 TANKDATA DS CL200 Data area in the tank 
DO TANKEND DS OF Force next to word boundary 
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TASK QUEUE ELEMENT: TASKE 


Fach task queue element contains status information pertaining to one 
active task. 


The TASKQ field of SVECTCRS points to this queue. 


Wa 
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Te a EE eae op ag ag ee eg eee ee 











0 | TASKNEXT | 
| { 
4 | TASKSAVE { 
I I 
8 | TASKNAME I 
I { 
Cc {| TASKSPAR { TASKSTAT | TASKID I 
[rE | 
TASKNEXT DS 1F Address of the next element 
on the task element queue 
TASKSAVE DS 1F Address of this task's Task 
Save Area (TAREA) 
TASKNAME ODS CL4 Task name specified by the 
task; 4 bytes long 
TASKSPAR DS AL2 Unused 
TASKSTAT DS 1x Status flags associated with 
the task 
defined in TASKSTAT 
WAITING EQU. x' 80! Flag set to 1 when task is 
nondispatchable 
LOCKLIST EQU) x*40O! Flag set to 1 while task is 
Waiting for the synch 
lock list 
LIMBO FQU x*OT!® Flag set to 1 when a task is 


being terminated 


TASKID DS 1X Number ID for the task; 1 
byte is assigned by 
supervisor when task is 
made active 
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TASK 


The task save area comprises the first 78 bytes of the storage area 


s 


AVE AREA: TAREA 


defined in each task's storage. 


ag gg Oy ag a ET Ge ie Oe EG ee ee ee ee ae ee 


0 | TPSW I 

4 | { 

8 TGREGO 
Cc TGREG1 
10 TGREG2 
14 TGREG3 
18 TGREGY 
1c TGREGS 
21 3GREG6 
24 TGREG7 
28 TGREG8 ; 
2c TGREGY 
30 TGREG10 
34 TGREG11 
38 TGREF12 
3c TGREG13 
40 TGREG14 | 
44 TGREG15 
48 TREQLOCK 


TPSW DS 1D PSW with which a temporarily interrupted task 
resumes execution 
TGREGO DS 1F Save area for general register 0 
TGREG1 DS 1F Save area for general register 1 
TGREG2 DS 1F Save area for general register 2 
TGREG3 DS 1F Save area for general register 3 
TGREG4 DS 1F Save area for general register 4 
TGREG5 DS 1F Save area for general register 5 
TGREG6 DS 1F Save area for general register 6 
TGREG7 DS 1F Save area for general register 7 
TGREGS DS 1F Save area for general register 8 
TGREGI DS 1F Save area for general register 9 
TGREG10 DS 1F Save area for general register 10 
TGREG11 DS 1F Save area for general register 11 
TGREG12 DS 1F Save area for general register 12 
TGREG13 DS 1F Save area for general register 13 
TGREG14 DS 1F Save area for general register 14 
TGREG15 DS 1F Save area for general register 15 


TREQLOCK DS 1F Synchronization lock used to signal 


whether or not a task has information 
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Request and Alert Elements 


INTRODUCTION 


The following pages provide information on the format and use of RSCS 
request and alert elements. These elements are used in task-to-task 
communication. 

The information provided includes: 


e The name of the module that builds the element 


e The function performed by the element 


A brief description of the element's usage 


The format of the element 


Operational notes to assist in understanding how the element is used 


The elements are grouped in this section as follows: 

e Request Elements Processed by DMTREX 

e Command Alert Elements for Commands Processed by DMTAXS 

e Command Alert Elements for Commands Processed by Line Drivers 

The function code, in byte 2 of each element, tells the alerted task the 


kind of alert request. The meaning of the remainder of the element is 
defined for that function code for that task. 
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Command Request Element 


BUILT BY: DMTNPT, DMTSML 


FUNCTION: Execute an RSCS operator command 


DESCRIPTION: This request element is passed by a line driver via 


GIVE/TAKE to the REX task in response to a command entry 


at a remote station. 


eae em ne pn wag te RY i ae ae Ss ge eG ee Pes Can Gis pg Dim yg 


0 {| Length | Function | Unused 
(n—1) | Code: x"00* | 
4 
RSCS Operator 


el 


I 
{ 
I 
i Command Line Text 
| 
| 
I 
{ 


OPERATIONAL NOTES: 


ce 


No response text is returned. Command responses are 


distributed via a call to DMTMGX. 


Command/Message Routing Request Element 


BUILT BY: DMNTVMB, DMTVMC, DMTNJIT 


FUNCTION: Process a command or message received by a line driver. 


DESCRIPTION: This request element is passed by a line driver via 
GIVE/TAKF to the REX task, to process to a command or 
message being received by the line driver from a remote 


systen. 


| {Function | [CMD x'50* | 

| Length | Code: | Unused [MSG X*B1t | 

l | xo | I | 

440 J | 
{ destination locid { 
+12] | 
| destination VMID { 
+20] | 
| origin locid { 
+28 |-—__-____________________________-_-___ | 
| origin VMID | 
+36] { 
| 


{ CMD/MSG text 
| ICR ee ee | 


OPERATIONAL NOTES: 
No response text is returned. 
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Message Request Element 

BUILT BY: DMTREX, DMTCMX, DMTAXS, DMTNPT, DMTSML, DMTPOW, DMTNJI, 
DMTVMB, DMNTVMC 

FUNCTION: Issue an RSCS message 

DESCRIPTION: This request element is passed via GIVE/TAKE to the REX 


task, to specify the construction and distribution of an 
RSCS message (by DMTMGX). 


CS a ee ee ee ae eg ae SS et a ete ea a Te 


8-byte Variable Substitution 
Values for Message Text 


0 { # =%Length { Function | Routing | Severity | 

| (n- 1) | Codes: x'Q2' | Code | Code | 

| I 

4 | | 

| Receiver locid ! 

| { 

{ | 

Cc | | 

I Receiver userid | 

{ | 

| { 

14 | Issuing Module Code I Action | 
| | Code 1 

{ | 

18 | Binary Message Number | Unused | 
I | { 

I I 

1c | ] 


i a a a ee 


OPERATIONAL NOTES: 
The routing code and severity code from the message 
definition (in DMTMSG) are used when not supplied in the 
message request element. If the message is not defined in 
DMTMSG, it is constructed using the specifications in the 
message request element, and the "variable substitution 
values" become the message text, unmodified. 


Routing codes: 
X*80" Local RSCS console 
X'4O' Remote addressee 
X*20' Local user 
X¥'10" Local VM/370 operator 


No response text is returned. 
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Restart Termin 


BUILT BY: 


FUNCTION: 


DESCRIPTION: 


ate Request Flement 


DSTSML, DMTNJI, DMTPOW 


To terminate a line driver task specifying a command to be 
executed after line driver deactivation. 


This request element is passed via GIVE/TAKE to the REX 
task to terminate the line driver task and execute the 
specified command. 


0 Ce a eee ee ee ee ne ee ee 


n-1 


& 


| Function | | 
| Codes: ! { 
| X*FO! | | 


command line 


n nie se rete cree cee amin ecsemameneensnnsansenemecanemmell 


OPERATIONAL NOTES: 


There are no error conditions for the restart terminate 
function, so no response is made. However, line driver 
tasks must issue a WAIT request following a call to GIVE 
for terminate because REX may not execute the request 
immediately. 


Terminate Request Element 





BUILT BY: 
FUNCTION: 


DESCRIPTION: 





DMTNPT, DMTSML, DMTVMB, DMTVMC, DMTNJI, DMTPOW 
Terminate line driver task. 
This request element is passed via GIVE/TAKE to the REX 


task, to terminate line driver operation in response to a 
DRAIN command. 


Co rr ae fe ge BOC ea ee SR a Oe TEA Pee ee ee rey ee en ee ee TD 
0 | Length | Function | | 
| 


(1) | Code: X'03"] { 


UH SS 


OPERATIONAL NOTES: 


There are no error conditions for the terminate function, 
So no response is made. However, line driver tasks must 
issue a WAIT request following a call to GIVE for 
terminate, because REX may not execute the request 
immediately. 
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Timer Request Element 


BUILT BY: DESTVMC, DMTSML, DMTPOW, DATNJI 


FUNCTION: To set a task internal timer. 


+0 -———————— 
| | Function | | 

| Length | Code: | | 

| x*'o7" | xoas | { 
{ 

| 





+4 | 
{ Timer interval in timer units 
| (high order bit must = 0) { 
+8 US] 


OPERATIONAL NOTES: 


The use and meaning of the fields are described below: 


Response Post Codes: 


Xx'80* —- nornal 


X'*81* - active timer interval replaced 
x'84" ~- request format invalid 


TIMER INTERVAL: Request field specifying, in timer units, 
the timer value to be set. One unit = 1/300 of a second. 
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File Request Element 


BUILT BY: DMTNPT, DMTSML, DMTPOW, DMTVMB, DMTVMC, DMTNJI 
FONCTION: Initiates or terminates processing of an input or output 
file. 


DESCRIPTION: This request element is passed via GIVE/TAKE to the AXS 
task by line drivers to effect local spool file access 
during communications with a remote station. 


Ga a ee Ee nee a a mPOA oo! Tae ee ee ee ke Pa) ee 
QO | Length {Function Code:| Unused {| Modifiers 
(X°13") | xX*O1", X*02',] { 

1 xttt, Kw! | | 


TAG Address 
I/O Area Address 


| 
1 
| 
{ 
| 
{ 
| 
I 
| 
1 
{ 
| 
Linkid | 

| 


I 
I 
| 
I 
I 
l 
I 
8 | 
{ 
I 
I 
I 
I 
| 
nnn a ed 


OPERATIONAL NOTES: 
The use and meaning of the various fields depends on the 
requested function, as described below. Certain fields 
may be updated during request processing. The (updated) 
file request element is returned to the requestor as a 
GIVE response. 
Open Input 


Function Code: x'01'! 
Modifiers: Unused. 


Tag Address: Response field which points to the opened 
file's active tag. 


I/O Area Address: Response field which points to a virtual 
page buffer containing the opened file's first VM/370 
spool data buffer. 


Linkid: Request field which specifies the requesting line 
driver's linkid. 


Response Post Codes: 
X'O8' Terminal system error 
X'O4' Wo file available 
X'02* Undefined linkid 
X'O1" Previously open file returned 
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Open Output 
Function Code: Xx'!11! 


Modifiers: xX'80': Do not return possible previously opened file 
X¥'20': Save output file on abnormal termination 


Tag Address: Request field which points to a prototype 
file TAG for the output file, constructed by the calling 
line driver. 


I/O Area Address: Response field which points to a virtual 
page buffer containing an I/0 table, a write CCW, and a 
buffer for processing the output file. 


Linkid: Request field which specifies the requesting line 
driver's linkid. 


Response Post Codes: 
X'O4' Error, file not opened 
X'02* Undefined linkid 
X'01' Previously open file returned 
Close Input 
Function Code: X02! 
Modifiers: 
X¥'80' Do not purge copy or file 
X'4O'* Purge all copies, and purge file 
X'20* Re-engueue file for further processing. 


Tag Address: Request field which points to the file's 
active TAG in DMTSYS, as supplied by open input. 


I/O Area Address: Unused 
Linkid: Unused. 


Response Post Codes: 
X'O4' Tag not found, close failed 


Function Code: X'12! 

Modifiers: X'40* Purge output file. 

Tag Address: Request field which points to a prototype 
file TAG for the output file, constructed by the calling 
line driver. This tag is used to update the parameters to 
be set for the output file. 


I/O Area Address: Request field which points to the file's 
I/O area, as supplied by open output. 


Linkid: Unused. 


Response Post Codes: 
X'O4'yI/O area not found, close failed 
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Line Alert Element 


BUILT BY: 


FUNCTION: 


DESCRIPTION: 


0 


e 


8 


DMTCMX 
Request line port allocation 
This alert element is passed to the LAX task (DMTLAX) to 


verify and reserve line ports for links being activated in 
response to a START command. 


Oe ee ee ae es ee EN ee a epee a ae iN aie Og ge ee kale eee eT 





Length [| Function [| Response | Unused | 
(X'OF*) | Codes xX'O1T'| Code J | 
i 

Line Address { Unused ] 

| | 

| 

| 

linkid | 

| 


OPERATIONAL NOTES: 


The use and meaning of the fields are described below. 
Certain fields are updated during processing. 


Response Codes: 
X'08" Specified line address not attached (CC=3) 
X'O4" Specified line address not valid RSCS port 
device type 
X'02* Line not available 


Line Address: Request field specifying requested line 
address. Zero specification implies request for 
allocation of a switchable line from the port table. If 
successful, the port's line address is returned in this 
field as a response. 


Linkid: Response field specifying the ID of the Link which 


has reserved the particular requested line address (with 
response code X'02'). 
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COMMAND ALERT ELEMENTS FOR COMMANDS PROCESSED BY DMTAXS 


BUILT BY: DMTCMX, UMTREX 

FUNCTION: Execute a file queue reorder. 
Wate ee ee eee Fe hee ee a ee ee a ee a ee ee ee 
{ Length | Function | Response | Modifiers | 
{ x'o3! { x'ot { Code { | 
nn eT | 


OPERATIONAL NOTES: 
Response Codes: 
X'00O' Element accepted for processing 
X¥'10" Element rejected, busy 


Modifiers: Unused 
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ORDER. PURGE, and CLOSE Command Alert Element 





BUILT BY: DMTCMX 
FUNCTION: Execute an AXS command 
DESCRIPTION: This alert element is passed to the AXS task (DMTAXS) to 


request second—level processing of an ORDER, PURGE, or 
CLOSE command. 











Ce en re ee pO en EP ee a ee POG ga gent Ea Coe Ca oe on —— 

0 { Length | Function | Response | | 
{ (n-1) | Codes X*10',X'11', | Code | Modifiers | 

| | x'12! | | | 

| | 

= i ! 
I locid | 

| { 

I I 

Cc f i 
° VMID 7 

| { 
104 | spoolid count { spoolid i 
1 (n-x' 17") 72 I | 

I ( 

18 | i | 
| 1 

1 spoolid i spoolid | 


| cn nn Tne | 


OPERATIONAL NOTES: 
The linkid field specifies the affected link and the 
command origin locid.  VMID specifies the command origin 
userid. The spoolid fields are binary halfwords; they | 
specify the files enqueued on the specified link which are 
to be reordered or purged. The spoolid count field is a 
binary halfword; it specifies the total number of spoolid 
fields present. The meanings of the other fields are: 


ORDER Command 


Function Code: x10? 


Response Codes: 
X'0O' Element accepted for processing 
X¥'10' Element rejected, busy 


Modifiers: 


X'80" Response messages go to local RSCS operator 
X'00* Response messages go to specified link/VMID. 
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PURGE Command 
Function Code: Xx'11! 


Response Codes: 
X'00' Element accepted for processing 
X'10' Element rejected, busy 


Modifiers: 
X'80' Response messages go to local RSCS operator 
X'4O" Purge all files enqueuved on the specified link 
X'0O* Purge only specified files; response messages go 
to specified link/userid 


Function Code: xX'12! 


Response Codes: 
X'00* Element accepted for processing 
X¥'10" Flement rejected, busy 


Modifiers: 
X'80" Response messages go to local RSCS operator 
X¥'4O" CLOSE both input and output files on the specified link 
K*20" CLOSE input files on the specified link 
X'10" CLOSE output files on the specified link 
X'00" CLOSE only specified spoolids. Response messages 
go to specified link/userid. 
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TRANSFER Command Alert Element 

BUILT BY: DMTCMX 

FUNCTION: Execute an AXS command. 

DESCRIPTION: This alert element is passed by a DMTCMX call to ALERTREQ 
to the AXS task (DMTAXS) to request second-level 
processing of the TRANSFER command. 

0 
{ Length | Function | Response | Modifiers | 
1 (n-1) | Code X'13" | Code t { 
4H | ' 
| linkid \ 
Cc | \ 
| VMID { 
4 | 1 
i new locid | 
1c | | 
{ new VMID | 
24 | | 
| spoolid count | spoolid { 
| (m-X'27") 7/2 1 i 
I | 
| | | 
I I 
n {f{ spoolid | spoolid ] 


| re | 


OPERATIONAL NOTES: 


The linkid field specifies the affected link and command 
origin locid. VMID specifies the command origin userid. 
NEW LOCID and NEW VMID are the new destination location 
and user IDs for the specified spoolids. The spoolid 
fields are binary halfwords and specify the files enqueued 
on the specified Link which are to be transferred. The 
SPOOLID COUNT field is a binary halfword and specifies the 
total number of spoolid fields present. The meanings of 
the other fields are: 


TRANSFER Command 





Function Code: Xx'13! 


Response Codes: 
X'QO' Element accepted for processing 
X'10' Element rejected, busy 


Modifiers: 


X¥*80" Response messages go to local RSCS operator 
X'0O' Response messages go to specified link/VMID 
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CHANGE Command Alert Element 
BUILT BY: DMTCMX 
FUNCTION: Execute AXS command 


DESCRIPTION: This alert element is passed by a DMTCMX alert to the AXS 
task (DMTAXS), to request second-level processing of a 
CHANGE command. 


ee a, ON ee ee pe ee ee elgg ge eee 


0 { Length | Function | Response | { 
1 (x*3B*) | Code: xX*'20! | Code | Modifiers | 

I | 

1 linkid { 

4 | { 
| VMID | 

| I 

14 [| spoolid ! priority | 
I I 

18 {| HOLD { CLASS { COPY | 
i | 

1c | | 
| I 

| Distribution Code | 

I { 

| I 

I ] 

24 | | 
. filename/filetype, dsname < 


OPERATIONAL NOTES: 
The linkid field specifies both the link on which the 
object inactive file is enqueued and the command origin 
locid. VMID specifies the command origin userid. The 
spoolid field is a binary halfword and specifies the 
object file's WM/370 RSCS identifier. 


The following fields are specified only when the 
corresponding file attribute is to be changed. If the 
field is not specified, it is set to all 1 bits 
(X*PF...'). 


e Priority halfword binary priority 0-99 
e HOLD X'7F* - set hold status 
X'3F' - reset hold status (NOHOLD) 

e CLASS 1-byte EBCDIC class, A-Z, 0-9 

COPY halfword binary copy count, 1-99 

e Distribution code 8-byte EBCDIC spool file 
distribution code 

e Filenane/filetype, dsname, 24-byte EBCDIC spool file 
filename or filetype or dsname 
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CHANGE Command 
Function Code: x'20! 


Response Codes: 
xX'00* Element accepted for processing 
X'10" Element rejected, busy 


Modifiers: 
X'80" Response messages go to local RSCS operator 
X¥*'00" Response messages go to specified link 


Initialize Acceptor Alert Element 


BUILT BY: 
FUNCTION: 


DESCRIPTION: 


+0 


DMTREX 
To inform the AXS Task that file acceptance may begin. 


Before profile execution, DMTAXS does not accept any files 
into its internal tag slot queve. After profile execu- 
tion, DMTREX alerts DMTAXS with an initialize acceptor 
alert element of the following format, that file 
acceptance is to begin: 


Oe fp ne ee te Pape ee ee ee ee a 
| Length{ X'FF' | xX*00" | X*OO* | 


1 x'o3* | | i { 
OU) Cn 
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COMMAND ALERT ELEMENTS PROCESSED BY LINE DRIVERS 








Format 

BUILT BY: DMTCMX 

FUNCTION: Execute a line driver command 

DESCRIPTION: This alert element is passed by a DMTCMX alert request to 
a line driver task (DMTNPT, DMTVMB, DMTVMC, DMTPOW, 


DMTNJI, DMTSML) to request second—level processing of a 
START, DRAIN, FREE, HOLD, or TRACE command. 


Ws af td rege Pe og Op Se a pee ee ae ey ee Pe ee ee ee ee 


0 | { Function I | 
| Length { Code: X*'80,X'81',] Response { | 

[ (x'13') } xX*82",X'83",X'84"'| Code { Modifiers | 

I | 

4 | | 
| { 

| locid I 

I | 

{ | 

Cc | I 
J VMID ] 
Ae ae Saenger re NE SR Se ne ee eT 


OPERATIONAL NOTES: 
The locid/VMID specifies the location/userid to receive 
response messages. The meanings of the other fields are: 


Function Code: x80! 


Response Codes: 
X'OO' Element accepted for processing 
X¥'10" Flement rejected, busy 


Modifiers: 
X'80* Start updated classes 
X'QOO' Reset DRAIN status 


DRAIN Command 








Function Code: x'81' 

Response Codes: 
X'00' Element accepted for processing 
x¥'10" Element rejected, busy 


Modifiers: Unused 
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Function Code: X'82! 

Response Codes: 
X¥'OO* Element accepted for processing 
X'*10" Element rejected, busy 


Modifiers: Unused 


i0 


i] 


Comman 


es 


Function Code: X'83! 


Response Codes: 
X'OO" Element accepted for processing 
X'10" Element rejected, busy 


Modifiers: 
X'80' HOLD Immediate 
X¥'00* HOLD after file processing 


TRACE Command 


Function Code: X'84' 


Response Codes: 
X'O00' Element accepted for processing 
X*10* Element rejected, busy 


Modifiers: 
X'80" Start sum reporting 
X'4Q" Stop sum reporting 
X¥*20" Start line logging 
X¥'*10* Stop line logging 
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It 
ibs 
ls 
Io 
IH 
- 
® 
Le] 
IO 


MMand (BACKSPAC, FWDSPACE) Alert Element Format 








BUILT BY: DMTCMX 

FUNCTION: Execute a line driver command 

DESCRIPTION: This alert element is passed by a DMTCMX alert request to 
a line second-level driver task (DMTNPT, DMTSML) to 


request second-level processing of a BACKSPAC or FWDSPACE 
command. 


Wr ae pe ee me ee oe pee tage De Set Sk gee gt a ey gt a ee 


0 | Length {| Function | Response | { 
| (K'17") | Codes x'90',xX'91° | Code | Modifiers | 
| { 

4 | { 
{ ! 
I locid I 

Cc | { 
| VMID { 
I I 

1H | i 
| Count { 
| | 


OPERATIONAL NOTES: 
The locid/VMID specifies the location/userid to receive 
response messages. The count field is a binary fullword, 
and specifies the number of units to be back spaced or 
forward spaced. The meanings of the other fields are: 


BACKSPAC Command 
Function Code: X'90! 
Response Codes; 
x'O0O" Element accepted for processing 
X'10' Element rejected, busy 
Modifiers: 


X*80" Backspace count 
X'OO" Backspace file (restart) 


FWDSPACE Command 


SS ee 





Function Code: x'91'* 

Response Codes: 
X'OO' Element accepted for processing 
X'10' Element rejected, busy 


Modifiers: Unused 
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BUILT BY: DMTCMX 
FUNCTION: Execute a line driver command 
DESCRIPTION: This alert element is passed by a DMTCMX alert request to 


14 


a line driver task (DMTNPT, DMTSML) to request second- 
level processing of a FLUSH command. 


Ce ee en ee ee ee ee ee ee ee ee ee 
Length [{ Function {| Response | 
(X'15") {| Codes: KAO? | Code | Modifiers 


locid 


VMID. 


Spoolid ! 


OPERATIONAL NOTES: 


The locid/VMID specifies the location/userid to receive 
response messages. The spoolid field is a binary 


halfword, and specifies the VM/370 RSCS identifier of the 


active file to be flushed. The meanings of the other 
fields are: 





Function Code: X*aA0o! 


Response Codes: 
X'00" Element accepted for processing 
Xx'10* Flement rejected, busy 


Modifiers: 
X¥*80" Flush all copies, purge file 


X'40" Flush hold, keep file, do not decrement copy count 
X'0O" Flush, decrement copy count, purge file if no copy 


count remains 
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Line Driver Command (COMMAND, MSG, MESSAGE) Alert Element 














BUILT BY: DMTCMX, DMTMGX 

FUNCTION: Execute a line driver command 

DESCRIPTION: This alert element is passed by either a DMTCMX or DMTMGX 
alert request to a line driver task (DMTNPT, DMTPOW, 


DMTSML) to forward messages, and to request second-level 
processing of a CMD command. 


Cp ee PN ee a ET Cp get Ew ope pie a! a) Vee a ee 


0 | Length { Function | Response | ] 
| (n-1) {| Code: X*BO',X'B1* | Code | Modifiers | 

I | X'B2!° | t I 

| I 

4 | | 
I destination locid | 

{ | 

12 | | 
| destination VM/370 ID | 

| I 

20 | | 
j origin locid | 

I | 

28 | | 
i origin VM/370 ID | 

I i 

36 | t 
| [ 


CMD/MSG text 


OPERATIONAL NOTES: 
The locid specifies the location to receive the message or 
command text. Meanings of other fields are: 


In 


D Command 





Function Code: X'BO® 


Response Codes: X'00* Element accepted for processing 
x'10" Element rejected, busy 


Modifiers: Unused 
MSG Command 
Function Code: xX'Bt1! 


Response Codes: X'00' Element accepted for processing 
X'10' Element rejected, busy 


Modifiers: Unused. 
Function Codes: X*B2! 


Response Codes: X'00' Element accepted for processing 
xX'80" Element rejected, busy 


Modifiers: One-byte binary RSCS severity code 
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NETWORK CONNECTION CCNTROL RECORDS 








Initial Signo 
NCCRCB BC 
NCCSRCB DC 
NCCISRCB EQU 
NCCRSRCB EQU 
NCCIDL DC 
NCCINODE DC 
NCCIQUAL DC 
NCCLEVNE vc 
NCCIREST DC 
NCCIBFSZ DC 
NCCILPAS DC 
NCCINPAS DC 
NCCIFLG DC 
NCCIFLGM EQU 
NCCIL EQY 
NCCI END DC 
Concur /Reset 5 
NCCRCB DC 
NCCSNB DC 
NCCESRCB EQU 
NCCCSRCB EQU 
NCCCDL DC 
NCCCEVNT DC 
NCCCREST DC 
NCCEREST DC 
NCCCL EQU 
NCCCEND DC 


n 


Control Record and Response Signon Control Record Format 





K' FO! 

X'O! 

cty 

cg 

AL1 (NCCIL) 


x'or 

B* 10000000! 
*~-NCCRCB 
X'or 








Generali record controi byte 
Sub-record control byte 
Initial SIGNOW character 
Response SIGNON character 
Length of logical record 

Node identification 

Qualifier if shared spool 

Event sequence number 

Partial node to node resistance 
Maximum transmission block size 
Line password 

Node password 

Feature flags 

Multiple trunk (response) 


End RCB 


ignon Control Record Format 


X' FO! 

xO 

c'K? 

c'ht 

AL 1 (NCCCL) 
FLG'Q? 
OHL2'0! 
HL2* 0° 
*-NCCRCE 
X'or 





General record control byte 
Sub-record control byte 

Reset SIGNON character 

Concur SIGNON character 

Length of logical record 

Event sequence number 

Total node to node resistance 
Partial node to node resistance 


End RCB 


Add/Subtract Connection Control Record Format 


NCCRCB 
NCCSRCB 
NCCASRCB 
NCCSSRCB 
NCCADL 
NCCANODA 
NCCAQULA 
NCCANODB 
NCCAQULB 
NCCAEVNT 
NCCA REST 
NCCAL 
NCCAEND 


DC 
DC 
EQU 
EQU 
DC 
DC 
DC 
DC 
DC 
DC 
DC 
EQU 
DC 


Cc'nt 

AL 1 (NCCAL) 
cL8* ! 
xo! 

CL8* ¢ 
x'o! 

FL4' 08 
HL2‘0O! 
*-NCCRCB 
X'Q? 


Section 5: 


General record control byte 
Sub-record control byte 

Add connection character 
Subtract connection character 
Length of logical record 
Lower node identification 
Qualifier if shared spool 
Higher node identification 
Qualifier if shared spool 
Event sequence number 

Node to node resistance (total) 


End RCB 
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NETWORK JOB HEADER RECORD FORMAT: NJHDSECT 


x 


NJHLEN 
NJHFLAGS 
NJHS EQ 
NJHLBCI 


* 


NJHG 
NJHGLEN 
NJHGFLGS 
NJHGTYPE 
NJHG MOD 
NJHGSMOD 


NJHGJID 

NJHGJCLS 
NJHGMCLS 
NJHGFLG1 
NJHGPRIO 
NJHGORGQ 
NJHGJCPY 
NJHGLRCT 


NJHGACCT 
NJHGUNAN 
NJEGUSID 
NJHGPASS 
NJHGNPAS 
NJHGETS 

NJHG ORGN 
NJ HGORGN 
NJHG XEQN 
NJHGXEQU 
NJHG PRIN 
NJHGPRTR 
NJHGPUNN 
NJHG PUNR 
NJHGFORSA 
NJHGICRD 
NJHGETIA 
NJHGELIN 
NJHGECRD 
NJHG PRGN 
NJHGROOM 
NJHGDEPT 
NJHGBL DG 
NJHG NREC 
NJHGEND 

NJHGLLEN 


Block Control Information 


pc 
DC 
Dc 
EQU 


General Section 


DS OF 

DC AL2(NJHGLLEN) 
DS OBL2 

DC AL1(NTYPGEN) 
DC AL1 (NJHGSMOD) 
EQU B* 00000000! 
pc (0) 

Dc Ctat 

pc CA! 

DC B*00000000' 
DC AL1(0) 

DC AL1(0) 

pc AL1(0) 

DC AL1(0) 

pC XL3*'00! 

DC cLs! ! 

pe cis" * 

DC cCL8' ! 

DS CL8 

DS C18 

DC FL8'O! 

pc c1s' 

pc CL8' ' 

pc cre! ' 

pc CLs" ! 

pc CL8! 

pc cis! 

pc CLs! ! 

pc cig! '* 

DC CL8' ! 

Dc FO? 

pc FO! 

pc FQ? 

Dc FO! 

pc CL20* ' 

pc cLs' ' 

pc cis! ¢ 

pc CLs! ¢ 

pc FO? 

DS OF 

EQU *-NJHG 


AL2 (NJHLLEN) 


x'o0o! 


BL.1'0',AL.7 (0) 
*-NJHDSECT 


Length of entire block 

Flags 

Transmission sequence indicator 
Length of block control information 


Start of general section 
Length of general section 
Section type flags 

ID for general section 

Modifier 

Value of modifier 


Job identifier 
Job class 
Message class 
Flags 
Selection priority 
Origin node system qualifier 
Job copy count 

Job line count 

Reserved 
Networking account number 
Job name 
User ID (TSO, VM/370) 
Password 
New password 
Entry time/date stamp 
Origin node name 
Origin remote name 
Execution node name 
Execution user ID (VM/370) 
Default print node name 
Default print remote name 
Default punch node nane 
Default punch remote name 
Job forms 
Input card count 
Estimated execution time 
Estimated output lines 
Estimated output cards 
Programmer's name 
Programmer's room number 
Programmer"s department number 
Programmer's building number 
Record count on output 
End of general section 
Length of general section 
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NJH2 
NJH2LEN 
NJH2FLGS 
NJH2TYPE 
NJH2 MOD 
NJH2$MOD 


NJH2FLG1 


NJHZACCT 
NJH2 END 
NJH2LLEN 


NJHLLEN 


* 


NJHU 
NJHULEN 
NJHU FLGS 
NJHUTYPE 
* 


* 
NJHU MOD 
NJHUSMOD 


NJHUCODE 
* 


* 
NJHU EN D 
NJHULLEN 


* 


NTYPGEN 
NTYPSUB 
NTYPASP 
NTYPHASP 
NTYPJES 1 
NTYPJES2 
NTYPJES 3 
NTYPPOWR 
NTYPVYNET 


NTYPUSER 


* 


NJHGFIPR 
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DS OF Start of JES2 section 
DC AL2(NJH2LLEN) Length of JES2 section 
DS OBL2 Section type flags 

DC AL1I(NTYPJES2) ID for JES2 section 
DC AL1 (NJH2$MOD) Modifier 

EQU Bt00000000' Valud of modifier 

DC Bt00000000' Flags 

DC XL3'00! Reserved 

DC CLHF ¢ Originator‘'s JES2 account number 
DS OF End of JES2 section 
EQU *-NJH2 Length of JES2 section 
EQU *-NJHDS ECT Length of entire block 


Recommended Format for a User Section 


DS OF Start of user section 

DC AL2 (NJHULLEN) Length of user section 
DS OBL2 Section type flags 

DC AL1 (NTYPUSER) ID for user section -- 


Bits 0-1 must be B‘11' 
Bits 2-7 can be anything 


DC AL1(NJHU$MOD) Modifier -- 
EQU Bt00000000! Mod value can be anything 
DC cCL&4t ? SHARE/GUIDE installation code 


Place user information fields 
between '‘NJHUCODE' & '"NJHUEND! 
DS’ OF End of user section 
EQU *-NJHJ Length of user section 


Section Type Flags 


EQU B*' 00000000! General section 

EQU Bf10000000 § Subsystem section 

EQU B'10000001' ASP subsystem section 

EQU B*10000010! HASP subsystem section 

EQU B'10000011' JES/RES subsystem section 
EQU B*10000 100° JES2 subsystem section 

EQU B'10000101' JES3 subsystem section 

EQU B*10000110' VSE/POWER subsystem section 
EQU Bt10000111' VM/370 subsystem section 
EQU B*'11000000! User section 


General Section, NJHGFLG1 


EQU B'10000000' Do not recompute priority 


NETWORK JOB TRAILER RECORD FORMAT: NJTDSECT 


* 


NJTLEN 
NJTFLAGS 
NJTSEQ 
NJTLBCI 


Block Control Information 


DC AL2 (NUTLLENW) Length of entire block 

DC x00? Flags 

DC BL.3'0',AL.7(0) Transmission sequence indicator 

EQU *-NJTDSECT Length of block control information 
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NJTG 
NJTGLEN 
NITGFLGS 
NITGTYPE 
NJTGMOD 
NITGS$SMOD 


NJTGFLG 1 
NJTG XCLS 


NITGSTRT 
NJTGSTOP 
NIJTGACPU 
NJTGALIN 
NJTGACRD 
NITGEXCP 
NJTGIXPR 
NITGAXPR 
NITGIOPR 
NJTGAOPR 
NJTGEND 

NJTGLLEN 
NJTLLEN 


* 


NJTU 
NJTULEN 
NJTU FLGS 
NJTUTYPE 
* 


* 
NJTUSOD 
NITUSMOD 


NJTUCODE 
* 


* 
NJTU END 
NJTULLEN 


General Section 


DS OF 

DC AL2(NJTGLLEW) 
DS OBL2 

DC AL1(NTYPGEN) 
DC AL1(NJTG$MOD) 
EQU B'000000CO! 
DC B*00000000" 
pc Ctat 

DC XL2*0! 

DC FL8*'0! 

pc FI8'O! 

pC FO! 

pc FQ? 

pc FtO! 

pc F*o! 

DC AL1(0) 

DC AL1(0) 

DC AL1 (0) 

pc AL1(0) 

DS OF 

EQU *-NJTG 

EQU *-NJTDS ECT 
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Start of general section 
Length of general section 
Section type flags 

ID for general section 

Modifier 

Value of modifier 


Plags 

Actual execution class 

Reserved 

Execution start time/date 
Execution stop time/date 

Actual CPU time 

Actual output lines 

Actual output cards 

Excp count 

Initial XEQ selection priority 
Actual XEQ selection priority 
Initial output selection priority 
Actual output selection priority 
End of general section 

Length of general section 

Length of entire block 


Recommended Format for a User Section 


DC 
EQU 


be 


DS 
EQU 


OF 

AL2 (NUTOLLEN) 
OBL2 

AL1 (NTYPUS ER) 


AL1(NITUSMOD) 
B*00000000 * 
cLar 


OF 
*-NITU 


Start of user section 
Length of user section 
Section type flags 
ID for user section -- 
Bits 0-1 must be B'11%' 
Bits 2-7 can by anything 
Modifier -- 
Mod value can be anything 


SHARE/GUIDE installation code 

Place user information fields 
between "NJTUCODE' & ‘NJTOEND! 

End of user section 

Length of user section 


NETWORK DATA SET HEADER RECORD FORMAT: NDHDSECT 


* 


NDHLEN 
NDHF LAGS 
NDHS EQ 
NDHLBCI 


a 


NDHG 

NDHGLEN 
NDHGFLGS 
NDHG TYPE 
NDHGAOD 
NDHG $MOD 


NDHGNODE 
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Block Control Information 


AL2 (NDBLLEN) 
X"008 


BL.1"'O' ,AL.7 (0) 


*-NDHDS ECT 


General Section 


DS 
DC 
DS 
pc 
DC 
EQU 


pc 


OF 
AL2 (NDHGLLEN) 
OBL 2 

AL1 (NTYPGEN) 
AL 1 (NDHG$HOD) 
B*00000000' 


cLs! * 


Length of entire block 

Flags 

Transmission sequence indicator 
Length of block control information 


Start of general section 
Length of general section 
Section type flags 

ID for general section 

Modifier 

Value of modifier 


Destination node name 


IBM VM/370: RSCS Networking Logic 


Licensed Material - Property of IBM 


NDHG RMT 
NDHG PROC 
NDHGSTEP 
NDHGDD 
NDHGDSNO 
NDHGSEC 
NDAGCLAS 
NDHG NREC 
NDEGFLG 1 
NDHGRCF & 
NDHGLREC 
NDHGDSCT 
NDHGFCBI 


NDHGFORM 
NDHGFCB 
NDHGUCS 
NDHGXWTR 
NDHGEND 
NDHGLLEN 


* 


NDHV 
NDHVLEN 
NDHVFLGS 
NDHVTYPE 
NDHVMOD 
NDHV $MOD 


NDHVFLG 1 


NDHVCLAS) 


NDHVIDEV 


NDHV DIST 
NDHVF NAM 
NDHVFTYP 
NDHVPRIO 
N DHV END 
NDHVLLEN 


NDHLLEN 


* 


NDHA 
NDHALEN 
NDHAFLGS 
NDHATYPE 
NDHAMOD 
NDHA$MOD 


ND HAFLG 1 
NDHAFLCT 
NDHATRE P 


NDHATAB1 
NDHATAB2 
NDHATAB 3 
NDHATAB4 
NDHAFLSH 
NDHAMODF 
NDHACPYG 
NDHAEND 

NDHALL EN 


EQU 


cL8! 
CLs! 
cLs? 
C18! 
H'O! 
AL1 (0) 

Ctat 

Ft'O? 

B* 00000000! 
B*00000000' 
H'O? 

AL1(1) 

AL1 (0) 
XL2"00" 
cle! ¢ 

cL8* ¢ 

cL8' 

CL8' 

OF 

*-N DHG 


Destination remote name 
Proc invocation name 

Step name 

DD name 

Data set number 

Security level 

Output class 

Record count 

Flags 

Record format 

Max Logical record length 
Data set copy count 

3211 FCB index 

Reserved 

Forms ID 

FCB ID 

uc ID 

External writer ID 

End of general section 
Length of general section 


RSCS Subsystem Section 


DS 
DC 
DS 
DC 
DC 
EQU 


DC 
DC 
DC 
DC 
pc 


EQU 


EQU 


OF 

AL2 (NDHVLLEN) 
OBL2 
AL1(NTYPVNET) 
AL1 (NDHV$MOD) 
B‘ 00000000" 


B*00000000! 
Cra 

x'00! 
XL1'00' 
cLs' ° 
CLi2* * 
CL12* ¢# 

AL2 (0) 

OF 

*-N DHV 


*~NDHDS ECT 


Start of RSCS section 
Length of RSCS section 
Section type flags 

ID for RSCS section 

Modifier 

Value of modifier 


Flags 

VM/370 spool file class 
V4/370 origin device type 
Reserved 

VM/370 distribution code 
VM/370 file name 

VM/370 file type 

VM/370 transmission priorty 
End of RSCS section 

Length of RSCS section 


Length of entire block 


3800 Printer Characteristics General Section (Optional) 


DS 
EQU 


OF 

Y (NDHALLEW) 
OBL2 — 

AL1 (NTYPGEN) 
AL1(NDHAS$HOD) 
B*10000000* 


B*00000000' 
AL 1(0) 
xX'00* 
x'OO! 
C18 § 
CL8'* 
CL8?* 
C18 * 
cL8! 
cLs* * 
XL8* 00! 
OF 
*-NDHA 


Section 5: 


Start of 3800 char section 
Length of 3800 char section 
Flags and modifier 

ID for general section 

Modifier 

Value of modifier (3800 char) 


Flags 

Flash count 

Table reference character 
Reserved 
Translate table 
Translate table 
Translate table 
Translate table 
Flash cartridge ID 

Copy modification ID 

Copy groups 

End of 3800 char section 
Length of 3800 char section 


S&WN = 
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NDHAF1J 
NDHAF1BR 


* 


NDHC 
NDHCLEN 
NDHCFLGS 
NDHCTYPE 
NDHC MOD 
NDHCSMOD 


NDHCFLG1 
NDHC RCFM 
NDHCLREC 
NDHCEND 

NDHCLLEN 


* 


NDHU 
NDHULEN 
NDHUFLGS 
NDHUTYPE 
* 

* 
NDHUMOD 
NDHU $MOD 


NDHUCODE 
* 


x. 
NDHUEND 
NDHULLEN 


* 


NDHGFISP 
NDHGF1HD 
NDHGF1LG 
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3800 Characteristics General Section, NDHAFLG1 


EQU B'10000000° "OPTCD=J' specified 
EQU B' 01000000! "BURST=YES' specified 


Record Characteristics Change General Section 


DS OF Start of char change general section 
DC AL2(NDHCLLEN) Length of char change general section 
DS OBL2 Section type flags 

DC AL1(NTYPGEN) ID for general section 

DC AL1(NDHC$MOD) Modifier 

EQU B'01000000! Value of modifier (char change) 

DC Bt00000000* Flags 

DC Bt00000000! Record format 

DC AL2(0) Maximum logical record length 

DS OF End of char change general section 
EQU *-NDHC Length of char change general section 


Recommended Format for a User Section 


DS OF Start of user section 

DC AL2(NDAULLEN) Length of user section 
DS OBL2 Section type flags 

DC AL1(NTYP USER) ID for user section -- 


Bits 0-1 must be B11! 
Bits 2-7 can be anything 


DC AL1(NDHU$MOD) Modifier -- 
EQU B' 00000000! Mod value can be anything 
DC cCLUF t SHARE/GUIDE installation code 


Place user information fields 
between 'NDHUCODE! & '"NDHUEND' 
DS OF End of user section 
EQU *-NDHU Length of user section 


General Section, NDHGFLG1 


EQU B*10000000* Spin data set 
EQU B'01000000! Hold data set at destination 
EQU Bt00100000 § Job log indicator 


COMMAND/MESSAGE HEADER FORMATS 


NMRDSECT 
NMRF LAG 
NMRLEVEL 
NMRPRIO 
NMRTYPE 
NMRAL 
NMRTO 
NMRTONO D 
NMRTOQUL 
NMROUT 
NERF AM 
NMRFANOD 
NMRF MQUL 
NMRASG 
NMRL 

NMR 
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DSECT 

pe xo? Flag byte 

DC Ox'0O! Importance level (high 4 bits) 
pce xo Output priority (low 4 bits) 
DC xo! Type byte 

Dc xo! Length of message 

pC 6ocLgot ¢ To node 

DC cCL8 §! To node name 

DC xo To node qualifier 

DC XL8*Ot Local output informaton 

DC OCL9! § From node 

DC cCL8* * From node hame 

pC x0! From node qualifier 

DC) 6CL132* ° Message 


EQU *-NMRDS ECT 
EQU NMRDSECT,NMRL Alias for NMRDSECT with length 
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NMRFNORM 
NRF RTE 
NMRFOP 
NMRF FLG 
NMRFJID 
NMRF ORGN 
NMRFJUNAM 
NMRFD 
NMRFR 


* 


NMRUCH 
NMROUCMA 
NASRLINET 


* 


NMRDESC 
NMRROUT 
NARDOMID 


* 


NARRAT 


NHERUSER 


* 


NARFLAGC 
NARFLAGW 
NRAFLAGT 
NMRFLAGU 
NMRF LAGR 
NMRFLAGJ 
NRF LAGD 
NMRFLAGS 


* 


NMRTYPEX 
NMRTYPEF 


* 


NHRFOPD 
NMRFOPC 
NMRFOPA 
NMRFOPH 
NMEF OPR 


* 


NARFFLGO 
NMRFFLGD 
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Formatted Command Definitions 


ORG NMRMSG 

DC OXL20'O8 Formatted area for normal command 
DC OXL36'0! Formatted area for route command 
Dc xo! Op code 

pc x*o® Flags or op code modifier 

DC XL2'0! Initial job number 

pc 6€6cL8* 3 Origin node name 

Dc) 6CcL8* 6 ¢ Job name 

pc cLs! ! Destination for route command 

DC cCL8* ! Remote if not implied by NMRFD 


NMROUT Format for UCMID Messages 


ORG NMROUT 

pc xo? MCS console ID 

pc xo? MCS console area 

DC XL2‘0! Line type for MLWTO 


NMROUT Format for Logical Routed Messages 


ORG NMROUT 

DC XL2*08 MCS descriptor codes 
DC XL2'0° MCS console routings 
DC XL&of MCS DOM ID 


NMROUT Format for Remote Messages 


ORG NMROUT 


DC cL8 *' Remote name ‘rnnn . 


DMROUT for TSO User Messages 


ORG NMROUT 
pc cL8 # TSO user ID 
NMRFLAG Definitions 


NMRMASG contains a command 

NMROUT has JES2 remote number 
NMROUT has TSO user ID 

NMROUT has UCMID information 
Console is only remote authorized 
Console not job authorized 
Console not device authorized 
Console not system authorized 


EQU B'10000000' 
EQU B*01000000! 
EQU Bt00100000! 
EQU Bt 00010000! 
EQU B*00001000! 
EQU B'00000100! 
EQU B'00000010" 
EQU B'00000001' 


NMRTYPE Definitions 


Reserved bits 
Formatted command in nmrnusg 


EQU B*11110000° 
EQU 2 


NMRFOP Definitions 


EQU 1 Display job command 
EQU 2 Cancel job command 
EQU 3 Release job command 
EQU 4 Hold job command 
EQU 5 Route job command 


NMRFFLG Definitions 


EQU x*80! 
EQU x*4Q! 


Cancel or route output 
Cancel execution with dump 
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Section 6: Diagnostic Aids 


Problem Determination 


The complexity and physically dispersed nature of data telecommunication 
systems can lead to difficulty in diagnosing malfunctions. Because many 
different problems with the various system components can present 
external symptoms which appear identical at the operator and user level, 
it is important to collect as much physical documentation pertaining to 
the malfunction as possible. Such documentation may include virtual 
storage dumps of the RSCS virtual machine, the RSCS operator console 
hard copy output, a log trace of the line I/O activity, and copies of 
files received in error. 


In the event of a definite program error that can be detected by the CPU 
or channel hardware (e.g., program checks), or by the RSCS systen 
itself, a virtual storage dump is automatically taken by means of a CP 
DUMP command executed by a DIAGNOSE X*'08* instruction. In this case, 
the RSCS operator console output normally includes a terminal diagnostic 
error message, as well as information concerning the activity leading up 
to the error. Any available console output containing such information 
should be retrieved and attached to the virtual storage dump. 


In many cases, minor malfunctions detectable by users, operators, and 
system programmers do not result in automatic virtual storage dumps. 
These malfunctions usually leave some evidence in RSCS virtual storage 
following their occurrence, and a dump of RSCS virtual storage can be 
useful if taken quickly after the malfunction occurs, before subsequent 
processing obscures the evidence, When a malfunction is detected, RSCS 
processing should be suspended by using the RSCS virtual machine console 
to place the virtual machine in CP console function mode (normally, by 
use of the ATTENTION key). Having entered CP console function mode, the 
following CP command should be entered: 


DUMP O- * (comment describing symptoms) 


When CP has confirmed DUMP command completion, the following two CP 
commands should be entered: 


CLOSE £E 
BEGIN 


The CLOSE command causes the storage dump print file to be queued for 
real printer output, and the BEGIN command causes RSCS to resume 
processing from where it was suspended. The character string to the 
right of the asterisk is printed as entered at the start of the dump 
listing; it should identify reason for taking the storage dump. All 
console listings (including the DUMP command) and other documentation 
should be retrieved and attached to the dump, and any further 
description of the problem should be written on the dump listing or 
attached to it. 


Suspected telecommunication problems should be documented by means of 
the RSCS TRACE command, using both the LOG and SUM keywords. A line 
activity log trace should be activated during the occurrence of the 
malfunction if possible. This presents no problem if the malfunction is 
constant or reproduceable at will, but intermittent or unpredictable 
malfunctions can sometimes be difficult to "catch". Line activity 
logging is initiated by the RSCS command: 
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TRACE ‘linkid' LOG 


and is terminated by the RSCS command: 
TRACE ‘linkid' NOLOG 


The log trace is automatically scheduled for real printer output on 
termination of logging, which should be done several seconds or minutes 
after the malfunction has occurred. (Avoid allowing log trace to remain 
active for long periods, since this can generate a very large printer 
spool file which may exhaust ¥M/370 system spooling space.) The log 
trace printed output should be retrieved, annotated with any descriptive 
comments, and attached to pertinent console output showing the trace 
commands and to a virtual storage dump taken immediately following the 
malfunction, as described above, (A virtual storage dump may be taken 


while log trace is active without any conflict.) 


If it is suspected that spool files are being altered in transmission 
(resulting in partial files, missing or duplicated records), copies of 
the original and altered files should be retrieved if possible. When a 
CMS DISK DUMP file cannot be loaded by a CMS DISK LOAD command due to 
file format errors, a CMS READCARD command should be issued to obtain an 
exact copy of the altered file. Other documentation of the problen 
(console output listings, line log trace, and virtual storage dump) 
should be obtained as described above, if possible. 


The documentation of a malfunction should be analyzed to diagnose the 
problem and identify the malfunctioning system component, if possible. 
There is no standard procedure for this kind of analysis. In general, 
system documentation and program listings can be used to determine 
normal system behavior which should appear in the log traces, dumps, 
etc, Any deviations or intermittent behavior would be suspect, and 
should be investigated, Often such discoveries sufficiently specify a 
particular malfunction to allow identification of a responsible routine 
Or component which can be easily analyzed and tested in detail. 


For example, suppose the diagnostic information indicates apparently 
normal communication, with a very high transmission exchange rate as 
indicated by the TRACE linkid SUM command, and no file data transfer. 
Analysis of a storage dump and log trace could show that a single 
CMD/MSG element is being repeatedly exchanged on the link. This 
suggests that a loop exists in the network routing structure in the 
user-defined RSCS directories at the network locations. In other words, 
the CMD/MSG element may be addressed to a location that each side of the 
link has accidentally routed to the other, This frequent source of 
trouble can be corrected by identifying the erroneously routed location 
ID from the storage dump or log trace, and issuing a ROUTE locid OFF 
command on either side of the Link. 


When problems are determined, any diagnosis along with the problem 
documentation and proposed correction (if any) should be forwarded to 
the people responsible for maintenance of the component suspected to be 
in error. It is most important to include a complete description of the 
configuration of the system in use, including specific hardware types 
and models, particular software systems, modification levels, and any 
local modifications in use. 


To analyze a problem documented in an RSCS storage dump, you need to 
determine the status of the RSCS system tasks at the time of the dump. 
Lay out the dump with a visible marker such as a colored felt pen. 


The locations of the tasks, modules, save areas, queues, tables and 
indicators all start with the pointers in the SVECTORS table beginning 
at storage location X'200', and in the common areas addressed by the 
TVECTORS in SVECTORS. 
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The Data Area Aids diagrams (in Section 5 of this manual) help you use 
the SVECTORS and other system control data. Use these diagrams, source 
listings, and the data area and control block detailed descriptions 
(also in Section 5 of this manual) to determine such things as active 
I/O, inactive I/0, tasks awaiting dispatching, tasks that have issued 
waits on synch locks, etc. 


When a line driver task is executing and a dump condition occurs (for 
example, due to a program check) the name of the line driver is at the 
top of the dump. 


The SVECTORS ACTIVE field, one byte at address X'210', contains the id 
of the currently active task, If the value in this field is xX'00', the 
dispatcher has found no task in the task table that is ready to run, and 
the supervisor is either executing or waiting (according to current PSW 
wait bit) for an interrupt. The address at location X'211'-xX'213! 
points to the task element of the last task to be dispatched before the 
dump was taken. 


If a dump is automatically taken by RSCS, the active register contents 
at the time of error are stored, beginning with register 0, at location 
X*100B0'. 


The value in register 14 (at location x'10040') in this save area is 
usually the address that the most recently active task exited from (BALR 
14, 15). 


Module Message Directory 


The following list identifies the module code where the decisions are 
made to issue RSCS messages, 


Message Message 
SourcejNumber Generated Source| Number Generated 
Module{_ ID. at Label Nodule{ ID. at Label _ 


DMTAXM101I TAGPEND DMTAXM525E CHANGE 
DMTAXM102T ACCEPEND CLOFCHEK 
DMTAXM103E ACCEPUR2 ORDECHEK 
DMTAXM104T1 CLOOSCN2 PURGCHEK 
DMTAXM105I CLOIPGE1 TRANCHEK 
DMTAXM106I FILST RY DMTAXM526E CHANGE 
OPENPOOF CLOFCHEK 
DMTAXM1071 UNPECHEK ORDECHEK 
DMTAXH108E OPENRDER PURGCHEK 
DMTAXM109I REORD (ER) TRANCHEK 
REFILCON DMTAXM640I PU RGDONE 
DMTAXM111I CLOSCAN1 DMTAXM645I TRANDONE 
DMTAXM500I CLOFINIS 
DATA XMSO1E CLOSE DMTCMXOO1L CMXFINXT 
DMTAXM502E CLOFCHEK DMTC MX0031I CMxM003 
DMTAXM5201 CHANGE DMTCMXOO4T CMXM003 
DMTAXM5211 CHAN HO DMTCMXO05I CMXM00 30 
DMTAXM5221 CHANNOH DMTCMX 1701 MSGM170 
DMTAXM523T1 CHANSCAN MSGLENOK 
DMTAXMS5S24E CHANGE DMTCMX 17 11 MSGM170 
OR DEC HEK DMTCMX201E CMXLGOT 
PURGCHEK CMXMISS 
TRANC HEK DMTCMX202E A1TOCHK 
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Module} ID _ 


DMTCNX203E 


DMTCHUX204E 


DMTCMX205E 
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Generated 


at Label 


A1TRANLK 
DEFLK NEW 
DEFNOLNK 
QYOLINK 
QYCKROUT 
QYINACTV 
A1FLKGOT 
A1FSTOW 
CHALKGOT 
FLUASCAN 
L2FLKGOT 
QYOFILE 
QYOFNULL 
A1TOCHK 
ATINPUT 
A10UT PUT 
A1TRAMIS 
CHALKGOT1 
CHALKGT1 
CHANTERM 
CHASCAN 
CKRNGE 
CNXH204 
cP 
CPQIND 
CPQUERY 
CPQLOG 
CPQN204 
CPQNAMES 
CPQUSERS 
EXEC 
FLUMORE 
FORERR 
HT 
LOFOUL 
LOHOLD 
LOTRACE 
LITERS 
QYROUGO 
QYROU MIS 
QYTOOMCH 
QYOFILE 
QYOLINK 
QYOSYSTM 
ROFORMAT 
REORDER 
ROSCAN 
ROUTCONT 
SHUTDOWN 
STALKGOT 
A 1TOCHK 
CHACLASS 
CHACOPY 
CHAHOLD 
CHANOHOL 
CHAPRIOR 
FLUKEYWD 
LOTKEY WD 
ROCLASS 
ROKEEP 
ROZONE 


Message 


DMTCMX 206E 


DATCMX 208¥F 


DMTCHX209F 
DMTCMX210E 


DMTCMX 3001 
DMTCMX301E 
DMTCMX 30 2E 


DMTCMX 303E 


DMTCAX304E 
DATCMX310E 


DATC MX320E 


DMTCMX540I 
DMTCMX54 11 
DMTCMX542E 


DMTCMX543E 


DMTCMX 544E 


DMTCMX550I 
DMTCMX551E 
DMTCMX552E 
DETCMX560I 
DMNTCMX56 1E 
DMTCMX625I 


Source{Number Generated 


Module{ ID __ 


at Label 


ROLINE 
ROTASK 
ROTYPE 
CHACLASS 
CHACOPY 
CHADIST 
CHANAME 
CHAPRIOR 
LOHOLD 
LOTRACE 
L1FLKGOT 
QUERY 
ROCLASS 
ROCLHULT 
ROKEEP 
ROZONE 
ROLINE 
ROTASK 
ROTYPE 

A 1TOCHK 
CPQUSERS 
DISCONN 
MSGLNKGO 
MSGNOUSR 
CMXHIT 
C¥D 
CHDNOLOC 
MSG 
MSGNOLOC 
CMXALRDY 
CMXALRDY 
A 1TRAULK 
MSGNOLNK 
CMD 
CMXH303 
FORCE 
LOFLKGOT 
L1FLKGOT 
L2FLKGOT 
MSG 
CMXALRDY 
CMDNOLNK 
QY NOT ROU 
MSGNOLNK 
CMD 

MSG 
DEFDO 
DEFDO 
DEFINE 
DEFM542 
DEFN543 
DEFNEXT 
DEFNOLNK 
DEFDO 
DEFMS44 
DELDELET 
DELETE 
DELETE 
DISCH ARG 
DISCONN 
QYOSY625 
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Message Message 
Source [Number Generated Source|Number Generated 
Module! ID. at Label Modulej| ID at _Label 


DMTCMX626T QYOSYNIN STAMN751 
DMTCMX6271 QYOSYPLF 
DMTCMX630I CMX M630 DMTINI410I WRDONE 
ROUTGOT DMTINIG11R IPLDISK 
DMTCMX631I CMXM631 DMTINI412R RDORWRT 
ROUOFF DMTINI4G13R NUCCYLN 
DMTCMX632E CMXM632 DMTINIYS1E HEXERR 
ROUSET DMTI NI482E DECERR1 
DMTCMX633E CMXM633 DECLOOP 
ROUSET DECPACK 
DMTCMX6341 QYOSY NET DMTINI483E RDORWRT 
DMTCMX6361 QYROUGO1 IPLZERO 
QYOSYROU DNETINI4S8SE BADIPLD 
DMTCMX6371 CMXM637 DMTINIS85E NUCCYLN 
QYROUMIS DMTINI498S WRERROR 
ROUOFF DMTINI4G99T RDERROR 
DMTCMX6511I QYINACTV 
DMTCMX6521 QYM652 DMTI RXOOOLI IRXGOTTN 
QY1SNOD DMTIRXGOOL IRXGOTTN 
DMTCMX653I1 QYM653 DMTIRX4S49T GENTAGS 
DMTCMX6541 QY1QUGO DMTIRX4&50E GENGOOD 
DMTCMX655I1 QY1QUEUE GENNOTS 
DMTC MX6561 QY1ACTVE GENPARS 
DMTCMX6601 QY2STAT GENPSCAN 
QY M660 DMTIRX45S1E GENLINK 
DMTCMX661I QYM661 GENPARA 
DMTC MX662I1 QY2RSS GENPORT 
QYM662 GENROUTE 
DMTCM X6631 QYM663 GENSPSF 
DMTCMX664E QY2RSS GENTAGS 
OY M664 DMTIRX452E GENLOCAL 
QY2STAT DMTIRX453E GENPARM 
QY2VNOH DETIRX454E GENTAGS 
DMTCMX665I QY 1AM 665 DMTIRX455E GENROUTE 
DMTCMX6701 QYSYCON DMTIRX456E GENLINK 
DMTCMX671T1 QYM671 DMTIRX457E GENPORT 
DMTCMX672I QYM672 DETIRX458E GENPARM 
DMTCMX6731 QYM673 GENROUTE 
DMTCMX674T QYOSQNXT DMTIRX461E GENLOCAL 
QY1M674 GENROUTE 
DMTCMX675E EXECPROC DMTIRX 46 2E GENLINK 
EXECM 675 GENPARMS 
DMTCMX676E EXECPROC GENROUTE 
EXECN676 DMTIRX463E GENLINK 
DMTCMX677E EXECPROC DMTIRX464E GENLPTRY 
EXECMN676 GENPORT 
DMTCMX678E EXEC DMTIRX465E GENLOCAL 
EXECM678 GENLZTRY 
DMTCMX700I STALNGOT DMTIRX466E GENLTTRY 
DMTCMX7O1E STACREAT DATI RX4S67E GENLCTRY 
DMTCMX702E STACRE AT DMTIRX 468E GENLKTRY 
DMTCMX703E STACREAT DMTI RX469E GENTAGS 
DMTCMX704E STACREAT DMTIRX490T IRXDISCO 
DMTCMX705E STACRERR DMTIRXS91T IRXDISCO 
DMTCMX706E STACRERR GENFINIS 
DMATCMX70O7E STACRERR DMETIRX492T IRXGOTIN 
DMTCMX708E STACRERR DMTIRX493T IRXGOTTW 
DMTCMX709E STACRERR DMTIRX4S9O4T GENFINIS 
DMTCMX710E STAMAXER DMTIRX&95T TRXM495 
DMTCMX750E STANOTCL 
DMTCMX7511 CMXALRDY DMTNCH 108E VMSPGET 
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Message 


Source | Number 
Module} ID _ 


DMTNC M1411 
DMTNCM 1421 


DMTNC M1431 
DMTNCM 1461 
DMTNC M1471 
DMTNCM190E 
DMTNC MS11E 
DMTNCH5311I 
DMTNCM5701 
DMTNCM571E 
DMTNC M5801 


DMTNCM581E 
DMTNC M590T 
DMTNCM591E 
DMTNC M610 
DMTNCM6111I 


DMTNCM612E 
DMTNCM750E 
DMTNCA7521 
DMTNCM801T 
DMTNCM802TI 
DATNCM803T1 
DMTNC M810E 
DMTNCMB81ITE 
DMTNCM812E 
DMTNCN813E 
DMTNC M9OST 
DMTNCM914E 
DMTNCM915E 
DMTNCMO16F 


DATNHDI44I 
DMTNHDI45I 
DMTNHDI10E 
DMTNHD9171 


DMTNIT204E 
DMTNIT7O8E 
DMTNITII1E 
DMTNIT9I12E 
DMTNITI13E 


DMTNPTOT7OE 
DMTNPT108E 
DMTNPTI41I 
DATNPT 1421 
DMTNPT1431 


DMTNPTI44I 
DMTNPT 1451 
DMTNPT1461 
DMTNPT 1471 
DMTNPT1491 
DETNPT190E 
DATNPT510I 
DMTNPT511E 
DMTNPT5701 
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Generated 


at Label 


ISIO 
RISIO2 
SIGNCTCG 
EOJ 
RLOC1 
RDEOF 
VMSP1 
SBKFWDN 
SETFWD 
SETDRAIN 
SETDRER1 
RDORJ ECT 
RDRJECT 
SETFLS HG 
SETFL ERR 
SETFREF 
SETFRER1 
SETHOLD 
ALLHLD 
SETHLDIM 
SETHLDE1 
SETSTRT1 
SETSTART 
SETTR3 
LOGCLOSE 
SETTR2 
SETTR8 10 
SETTR 811 
SETTR8 12 
SETTR 813 
MC70K 
MC7A914 
MC7A915 
MC7A916 


OPENSCLP 
HOJOBTLP 
TAGSNERR 
HOJOBGO 


INTS NERR 
ISTORERR 
IBUFFERR 
IRESTERR 
INTPASER 


IOERRPR1 
VMSGET 
NPTEINIT 
NPTEINIT 
LINEDIS2 
LINEDROP 
PUTOPEN 
PUTCLS1 
GETGOT2 
GETPURGE 
TRPRT 
VMSP1 
GTBKMSG 
SBKFWDN 
SETDRAIN 


Nessage 


DMTNPT571E 
DATNPT580I 
DMTNPT581E 


DMTNPT590I 
DMTNPT59 1E 
DMTNPT600I 
DMTNPT6101 


DMTNPT611I 


DATNPT612E 
DATNPT750E 
DSTNPT7521 
DMTNPTS801I 
DATNPT802I 
DMATNPTS803I 
DMTNPT810E 
DMTNPTS1I1E 
DMTNPT812E 
DMTNPT813E 
DMTNPT9IO2ZE 
DATNPT903E 
DMTNPTIO4E 
DMHTNPTIOST 
DMTNPTIOTE 
DMTNPTO3UE 
DMTNPTI36E 


DMTPOWO70E 
DMTPOW 108E 
DMTPOW141I 
DMTPOW 1421 
DMTPOW143T 
DMTPOW 144T 
DMTPOW144T 
DMTPOW 1451 
DMTPOWT45T1 
DMTPOW 1461 
DMTPOW1471 
DMTPOW 1701 
DMTPOWI90E 
DMTPOW 5311 
DMTPOW531I 
DMTPOW5701 
DMTPOWS71E 
DMTPOW590I 
DMTPOWSITE 
DMTPOW6 101 
DMTPOW6111I 
DMTPOW612E 
DMTPOW750E 
DMTPOW75 21 
DMTPOWS801I 
DMTPOW 8021 
DMTPOWS03I 
DMTPOW810E 
DMTPOW811E 
DMTPOW812E 
DMTPOW813E 
DMTPOW9O 2E 


Source |Number 
Modulej ID 


Generated 


at Label 


SETDRER1 
GETFLUSH 
SETFLUSH 
GETFLSHE 
SETFREE 
SETFRER1 
GDGODNE 
SETHOLD 
GETFILE 
SETHLDIN 
GETFILE 
SETHLDE1 
SETSTRT1 
SETSTART 
SETTR3 
LOGCLOSE 
SETTR2 
SETTR 810 
SETTR8 11 
SETTR812 
SETTR8 13 
CONFCK1 
SPASSE 
SGNERR 
NPTGETX 
ENDSCAN 
PUTCLOSE 
GETGOT1 


IOERRPR1 
VMSPGET 
ISTO 
SIGNOK 
EOJ 
POPEN 
JOPEN 
PCLOSE 
UCLOSE 
RLOC1 


. RDEOF 


MRTCONT2 
VMSP1 
CMDNSUP 
MSGIGNW 
SETDRAIN 
SETDRER1 
SETFREE 
SETFRER1 
SETHOLD 
ALLELD 
SETHLDE1 
SETSTRT1 
SETSTART 
SETTR3 
LOGCLOSE 
SETTR2 
SETTR810 
SETTR811 
SFTTR812 
SETT R813 
MCTERR 
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Message Message 
Source]Number Generated Source|[Number Generated 
Module] ID. at Label 


Module] ID at label 


DMTPOW903E MC7 SETHLDIM 
DMTPOW9I05T MC7B DMTSML612E SETHLDE1 
DMTPOW9I08E POWLERR3 DMTSMNL7T50E SETSTRT1 
DMTPOW913E POWIERR1 DMTSML7521 SETSTART 
DMTPOWS4OE RREJECT DMTSML801I SETTR3 
DMTPOWS41E PCMDERR1 DMTSML80 21 LOGCLOSE 
DMTPOW942E PCMDERR2 DMTSML8031I SETTR2 
DMTPOW943E PCMDERRE3 DMTSML810E SETTR810 
DMTPOW944T WGET2 DMTSML811E SETT R811 
DMTPOW945T DEOJ DATSML812E SETTR812 
DMTPOWS46E POWIERR2 DMTSMNL813E SETTR8 13 
DMTSNL9IO1E SMLIERR1 
DMTREXOOOL REXICGOT TCTR 
DMTRE x002I TERLHIT DMTSML90 2E MC7ERR 
DMTREXO80E TERLHIT DMTSMLOO3E MC7A 
DMTRE x090T REXPTERM DMTSML9OSI MC7B 
DMTREX091T REXITERM DMTSMLIO6E SMLIERR2 
DMTRE X6791 EXECNSG TCTR 
DMTSMLO3Z4E JCLOSE 
DMTRG X1701 RGXMSG DMTSNL935E READCON 
DMTRGX171I RGXMSG 
DMTRG X300T1 RGXNTHR1 DMTVMB1411 VMRENAUT 
DMTRGX301E RGXNTHR1 DMTVMBI42T VMREW10 
DMTRG X302E RGXNTHR1 DMTVMNB1431 LINEDROP 
DMATRGX303E RGXNTHR1 VMRQUIT 
DMTRG X304E RGXNTHR1 DMTVMBT44T PUTOPEN1 
DMTRGX320E RGXNTHR1 DMTVMBI4G5I PUTDONE 
DMTRG X330E RGXMNSGER DMTVMB1461 GETGOTR 
DMTRGX331E RGXMSGER DMATVMB1I47I GETFDEOF 
DMTRG X332E RGXMSGER DMNTVMB 1481 GETGOT1 
DMTVMBS10I GETBKFIL 
DMTSMLOTOE IOERRPRET DMTVMB511E SBKFWDN 
DATSML108E VMSPGET DMTVMB5701I SETDRAIN 
DMTSMLI41I ISsIo DMTVMB57 1E SETDRER1 
DMTSML142T1 SIGNOK DMTVMB580I GETFLUSH 
DMTSML143I EOJ RRESET 
DMTSML 1441 JOUTPUT DMTVMBS81E GETFLSHE 
PCONT DATVMB590I SETFREE 
UOUTPUT DMTVMB5S91E SETFRER1 
DMTSMLI45I JCLOSE1 DMTVMB610I SETHOLD 
PCLOSE DMTVMB611I GETFILE 
UCLOSE SETHLDIM 
DMTSML146I RLOC1 DMTVMB612E SETHLDE1 
DMATSML147I RDEOF DMTVMB750E SETSTRT1 
DMTSML149I TRPRT DMTVMB7521 SETSTART 
DMTSML170I WGET2 DMTVMB58 1E SETFLUSH 
DMTSML190E VMSP1 DMTVMB801T SETTR3 
DMTSML5S10I RDBKMSG DMTVMB802I LOGCLOSE 
DMTSML511E SBKFWDN DMTV MB803I SETTR2 
DMTSML530I1 SETCMD DMTVMBS10E SETTR810 
DMTSML570I SETDRAIN DMTVMB811E SETTR811 
SUSRNPUN DMTVMB812E SETTR812 
DMTSML571E SETDRER1 DMTVMB813E SETTR813 
DMTSML5801I RDFLUSH DMTVMB9O05I PASSM905 
DMTSML5S81E SETFLUSH DMTVMB9O1T4E PASSM914 
RDFLSHER DMTVMBO18E PASSH918 
DMTSML5S90I SETFREE DMTVMBOI9E PASSMN919 
DMTSMLS91TE SETFRER1 
DATSML600I RDGODNE DMTVMC108E MAKEBLOC 
DMTSML610I SETHOLD DMTVMCIG1E CTCEINIT 
DATSML611I ALLBLD VMCEINIT 
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Message Message 

Source|Number Generated Source{Number Generated 
Module{ ID at Label Module] ID. at Label 
DMTVMC142I CTCWHAT DMTVMC610I SETHOLD 

RESPC HK DMTVMC6111I SETHLDIM 

DMTVMNC143I1 LINEDIS2 DMTVMC612E SETHLDE1 
DMTVMC144T PUTNHEAD DMTVMC750E SETSTRT1 
DMTVMC145I PUTCLOSE DMTVMC752I SETSTART 
DMTVMC146T GETGOT DMTVMC801I SETTR3 
DMTVMCI471I GETCONT DMTVMC80 21 LOGCLOSE 
DMTVMC511E SBKFWDN DMTVMC803I SETTR2 
DMTVMCS70I SETDR1 DMTVMNC810F SETTR8 10 
DMTVMC571E SETDRER1 DMTVMC811E SETTR811 
DMTVMC5S81E SETFLUSH DMTVMC812E SETTR812 
DMTVMC590I SETFREE DMTVMC813E SETTR813 
DMTVMC5S91E SETFRER1 

Trace Log 


Each line driver builds and executes channel programs to control its BSC 
telecommunication adapter. In the event of a malfunction, an analysis 
of these I/O transactions can often provide a quick problem diagnosis. 
RSCS will generate a printed sequential log of each channel progran 
executed by a line driver during an interval controlled by the "TRACE 
linkid LOG" and "TRACE linkid NOLOG" RSCS operator commands. 


Each I/O channel program log consists of one or more printed lines. The 
‘composite! CSW (an ORing of all CSWs presented for the I/0 device 
during execution of the channel program) appears in columns 44-57 on the 
first line of each transaction entry. If the "unit check" CSW status 
bit is set on, the telecommunication adapter sense byte appears in 
columns 59-60 to the right of the composite CSW. (The sense data are 
alvays zero when the unit check CSW status bit is zero.) The first CCW 
in the channel program for the I/0 transaction appears in columns 63-78, 
to the right of the composite CSW and sense byte, if present. If a 
command chaining or data chaining bit is set on in a CCW, the following 
printed log line describes the next CCW in the transaction's channel 
program. In this case, the CSW and sense byte fields are blank unless a 
TIC CCW follows the preceding CCW. When a TIC is encountered in the 
channel program, the character string C'<-----TIC' appears in columns 
44-53 of the log line, and the CCW which is the object of the TIC 
appears in the line's normal CCW field. 


Each line of the log must contain a non-TIC CCW. Columns 1-42 of each 
line contain the read or write buffer addressed by the CCW appearing on 
the line. For an ending CCW, the buffer is truncated according to the 
CCW count, decremented by the CSW residual count when the ending CCW is 
a READ. For non-ending CCWs, the entire buffer is logged according to 
the CCW count. When the buffer is too large to fit within the printed 
log buffer field, the first 14 and last 6 bytes of the buffer appear, 
separated by a double dash. When the CSW residual count indicates that 
no data were read by an ending READ CCW, a double dash appears in the 
first two columns of the data buffer log entry. The contents of the 
RSCS log record are as follows: 


1-42 The data buffer described by the CCW to the right, truncated 
according to the CCW count, the CCW residual count and space 
constraints. 
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44-57 Bytes 1-7 of the composite ending CSW, on the first line of a 
transaction log. 


59-60 The sense byte, if any. 
63-78 A CCW included in the line transaction channel prograr. 


81-120 The graphic EBCDIC representation of the first 40 bytes of the 
data buffer (DMTPOW line driver only). 


The fields of the record are separated by blanks. The following are 
samples of read and write log records for NPT: 


2D 0797E00C000003 02079 BF820000004 
1070 0798280CO00TAC 0107987A60000002 
1002E2C9C7D5D6 D540404 0E3C 5E2- 404 040404003 02079 BF8 20000200 
1061 079828 0D0001FF 0107987A60000002 
37 02079BF820000200 


mi 0797E00F000004 01 02079BF820000004 
“- 0797E00E000004 01 02079BF 820000004 


First 14 bytes [Last 6 bytes| CSW {Sense | CCW 
| I | Byte | 


SASSER AS SS See SS SSeS SSeS SRS SSS eS I { { 
TP Buffer I I I 


Note: The dashes in record positions 1 and 2 indicate that there was no 
data transfer for that I/O transaction. 
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Appendix A: MULTI-LEAVING Description 


"MULTI-LEAVING" is the name of a computer-to-computer communication 
protocol developed for use by the HASP system and used by RSCS. 
MULTI-LEAVING can be defined as the fully synchronized, 
pseudo-simultaneous, bidirectional transmission of a variable number of 
data streams between two or more computers using Binary Synchronous 
Communications (BSC) facilities. 


MULTI-LEAVING in RSCS 


This appendix contains an overview of a comprehensive MULTI-LEAVING 
communications system (as is used in HASP/ASP). The VM/370 support for 
programmable BSC workstations is consistent with the MULTI-LEAVING 
design, but it does not use certain features provided in MULTI-LEAVING: 


e The transmission of record types other than print, punch, input, 
console, and control is not supported. 


e The only general control record type used is the terminal sign-on 
control. 


e Only SCB count units of 1 are used. 

e Column binary cards are not supported. 

In addition, the support provided for the MULTI-LEAVING based protocol 
used by VSE/POWER differs from that provided for HASP-type systems in 


the following areas: 


e A Request-to-Initiate Function transmission is required before all 
data transmissions. 


e No SCB fields are present in the General Control Record type records. 


e Carriage control information is not carried in the SRCB. 


MULTI-LEAVING Philosophy 


The basic element for MULTI-LEAVING transmission is the character 
string. One or more character strings are formed from the smallest 
external element of transmission, the physical record. These physical 
records are input to MULTI-LEAVING and may be any of the classic record 
types (card images, printed lines, tape records, etc.). For efficiency 
in transmission, each data record is reduced to a series of character 
strings of two basic types: 


1. A variable-length nonidentical series of characters 


2. A variable number of identical characters 
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Character Strings and the SCB 


An eight-bit control field, termed a String Control Byte (SCB), precedes 
each character string to identify the type and length of the string. 
Thus, a string as in 1 above is represented by an SCB followed by the 
nonduplicate characters. A string of consecutive, duplicate, nonblank 
characters (as in 2 above) can be represented by an SCB and a single 
character; the SCB indicates the duplication count, and the character 
following it is the one to be duplicated. In the case of an all-blank 
character string, only an SCB is required to indicate both the type and 
the number of blank characters. 


A data record to be transmitted is segmented into the optimum number of 
character strings (to take full advantage of the identical character 
compression) by the transmitting program. A special SCB is used to 
indicate the grouping of character strings in the original physical 
record. The receiving program can then reconstruct the original record 
for processing. 


Transmission Blocks and the RCB 


To allow multiple physical records of various types to be grouped 
together in a single transmission block, an additional eight-bit control 
field precedes the group of character strings representing the original 
physical record. This field, the Record Control Byte (RCB), identifies 
the general type and function of the physical record (input strean, 
print stream, data set, etc.). <A particular RCB type has been 
designated to allow the passage of control information between the 
various systems, Also, to provide for simultaneous transmission of 
Similar functions (that is, multiple input streams, etc.), a stream 
identification code is included in the RCB. 


A second eight-bit control field, the Sub-Record Control Byte (SRCB), is 
also included immediately following the RCB. This field is used to 
supply additional information concerning the record to the receiving 
program. For example, in the transmission of data to be printed, the 
SRCB can be used for carriage control information. 


MULTI-LEAVED Data Streams and the FCS 


For actual MULTI-LEAVING transmission, a variable number of records nay 
be combined into a variable block size, as indicated previously (that 
is, RCB, SRCB, SCB1, SCB2, ..., SCBn, RCB, SRCB, SCB1, ..., etc.). 
MULTI-LEAVING provides for two (or more) computers to exchange 
transmission blocks, containing multiple data streams as described 
above, in an interleaved fashion. To allow optimum use of this 
capability, however, a system must have the capability to control the 
flow of a particular data stream while continuing normal transmission of 
all others. This requirement becomes obvious if one considers the case 
of the simultaneous transmission of two data streams to a system for 
immediate transcription to physical I/0 devices of different speeds 
(such as two print streams). 


To meter the flow of individual data streams, a Function Control 
Sequence (FCS) is added to each transmission block. The FCS is a 
sequence of bits, each of which represents a particular transmission 
stream. The receiver of several data streams can temporarily stop the 
transmission of a particular stream by setting the corresponding FCS bit 
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Transmission Data Integrity and the BCB 


Finally, for error detection and correction purposes, a Block Control 
Byte (BCB) is added as the first character of each block transmitted. 
The BCB, in additional to control information, contains a module 16 
biock sequence count. This count is maintained and verified by both the 
sending and receiving systems to control lost or duplicated transmission 
blocks. 


In addition to the normal binary synchronous text control characters 
(STX, ETB, etc.) MULTI-LEAVING uses two of the BSC control characters, 
ACKO and NAK. ACKO is used as a "filler" by all systems to maintain 
communications when data is not available for transmission. WAK is used 
as the only negative response and indicates that the previous 
transmission was not successfully received. 


A typical MULTI~LEAVING transmission block looks like this: 


DLE BSC Leader (SOH if no transparency feature) 
STX BSC Start-of-Text 

BCB Block Control Byte 

FCS Function Control Sequence 

Fcs Function Control Sequence 

RCB Record Control Byte for record 1 

SRCB Sub-Record Control Byte for record 1 

SCB String Control Byte for record 1 

DATA Character String 

SCB String Control Byte for record 1 

DATA Character String 

SCB Terminating SCB for record 1 

RCB RCB for record 2 

SRCB SRCB for record 2 

SCB SCB for record 2 

DATA Character String 

SCB Terminating SCB for record 2 

RCB Transmission Block terminator 

DLE BSC Leader (SYN if no transparency feature) 
ETB BSC Ending Sequence 


MULTI-LEAVING Control Specification 


This section describes the bit-by-bit definitions of the various 
MULTI-LEAVING control fields and includes notes concerning their use. 


BLOCK CONTROL BYTE (BCB) 


Binary Meaning 
Leese cece Reserved (must be 1) 
me o & Sarre a Control information as follows: 
-000 ...-. - Normal block 
-001 .... - Bypass sequence count validation 
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-010 cccc - Reset expected block sequence count 
to "cccc" 

-0O11 .... ~- Reserved for future use 

-100 ...- ~ Reserved for future use 

-101 .... - Not used 

110 .... - Not used 

111 ...- ~ Reserved for future use 


eoee COCC Module 16 block sequence count 
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Leese 


oQe« 
‘o Vet 


e eI 


@eee Leee 


@e@ee 


Tees 


a Leake 


ace le 


| 


eeece 


e IT 


Pa a 


eeevw8e 


weee 


@eee 


eeee 


Tees 


ot.. 


ele 


selerl 


Meaning 
Reserved (must he Teee eeese Ieee even) 


Normal state 
Suspend all stream transmission (WAIT-A-BIT) 


Reserved for future use 
Remote console stream identifier 


Function stream identifier for: 
RJE input stream number 1 
RJE print stream number 1 
NJI/NJE job transmission stream number 1 


Function stream identifier for: 
RJE input stream number 2 
RJE print stream number 2 
RJE punch stream number 7 
NJI/NJE job transmission stream number 2 
NJI/NJE SYSOUT transmission stream number 7 


Function stream identifier for: 
RJE input stream number 3 
RJE print stream number 3 
RJE punch stream number 6 
NJI/NJE job transmission stream number 3 
NJI/NJE SYSOUT transmission stream number 6 


Function stream identifier for: 
RJE input stream number 4 
RJE print stream number 4 
RJE punch stream number 5 
NJI/NJE job transmission stream number 4 
NJI/NJE SYSOUT transmission stream number 


ol 


Function stream identifier for: 
RJE input stream number 5 
RJE print stream number 5 
RJE punch stream number 4 : 
NJI/NJE job transmission stream number 5 
NJI/NJIE SYSOUT transmission stream number 4 


Function stream identifier for: 
RJE input stream number 6 
RJE print stream number 6 
RJE punch stream number 3 
NJI/NJE job transmission stream number 6 
NJI/NJE SYSOUT transmission stream number 3 


Function stream identifier for: 
RJE input stream number 7 
RJE print stream number 7 
RJE punch stream number 2 
NJL/NJE job transmission stream number 7 
NJI/NJE SYSOUT transmission stream number 2 


Function stream identifier for: 


RJE punch stream number 1 
NJIL/NJE SYSOUT transmission stream number 2 
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RECORD CONTROL BYTE 


Binary * 


0000 


1101 
1110 
1111 
1001 
Viii 
1001 
111i 


Viii 


VWiii 


0000 
iiii 


0000 


0000 


0000 


0000 
0000 
0000 
0001 
0001 
0010 
00 10 
0011 
0100 
0101 
0110 
0111 
1000 
1001 
10 10 
1010 
1011 
1011 
1100 
1101 
1110 


1111 


Hex 


00 
01-8F 
90 


AO 


co 


DO 
EO 
FO 
91 
A1-F1 
92 
A2-F2 
93-F3 
94-F4 
95-F5 
96-F6 
97-F7 
98-F8 
99-F9 
9A 
AA-FA 
9B 
AB- FB 
9C-FC 
9D-FD 
9E-FE 


9F-FF 
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(RCB) 


Meaning 
End-of-block 
Reserved for future use 


Request to initiate function 
(SRCB=RCB of function) 


Permission to initiate function 
(SRCB=RCB of function) 


Acknowledge of transmission complete 
(SRCB=RCB of function) 


Not used 

BCB sequence error 
General control record 
RJE console message 
Reserved for future use 
RJE operator command 
Reserved for future use 
RJE input record 

RJE print record 

RJE punch record 

Data set record 
Terninal message routing request 
NJI/NJE input record 
NJI/NJE SYSOUT record 
NJI/NJE operator command/me ssage 
Reserved for future use 
Reserved 

Reserved for future use 
Reserved for future use 
Not used 

Not used 


Not used 


* i denotes a position whose value (1 or 0) depends on the 
hexadecimal value within the range in the column labelled "Hex." 
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91 


92 


93-F3 


94-F4 


95-F5 


96-F6 
97=F7 


98-F8 





None 

RCB of function to be initiated 

RCB of function to be initiated 

RCB of function to be cancelled 

RCB of function which is complete 
Expected count (received count is in BCB) 


An identification character as follows: 
Initial RJE SIGN-ON 

Final RJE SIGN-OFF 

Print initialization record 

Punch initialization record 

Input initialization record 

Data set transmission initialization 
System configuration status 
Diagnostic control record 

Initial network SIGN-ON 

Response to initial network SIGN-ON 
Reset network SIGN-ON 

Accept (concurrence) network SIGN-ON 
Add network connection 

Delete network connection 

Reserved for future use 

Unused 


Neo Setting Gym | ats oO 0 oD 


vin at at nt at at ae 


no 
' 


1000 0000 (x'80*) 
0000 0000 (xX'00') if VSE/POWER EOF record 


1000 0000 (x'80*) 
1110 1001 (X*"E9') if VSE/POWER PSTOP LINE command 
0000 0000 (x'00') if VSE/POWER EOF record 


1000 0000 (x'80') 
1000 0001 (xX*81") if VSE/POWER 
0000 0000 (x'00') if VSE/POWER EOF record 


Carriage control information as follows: 
1010 00nn - Space immediately "nn" spaces (not used) 
1011 cccc - Skip immediately to channel "cccc" (not used) 
1000 OOnn - Space "nn" lines after print 
1000 1100 - Load printer FCB image 
1001 cccc - Skip to channel "cccc" after print 
1000 0000 - Print and suppress space 
1000 0001 (xX'81") if VSE/POWER 
0000 0000 (x'00') if VSE/POWER EOF record 


1000 1111 (X*8F*) 
0000 0000 (x'00') if VSE/POWER EOF record 


Undefined 
Undefined 
NJI/NJE input control information as follows: 


1000 0000 - Normal input record 
1100 0000 - Job header 
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1110 0000 - Data set header 
1101 0000 - Job trailer 
1111 0000 - Data set trailer (not used) 


NJI/NJE SYSOUT control information as follows: 
10cc 0000 - Carriage control type as follows: 
1000 0000 - No carriage control 
1001 000 - Machine carriage control 
1010 0000 - ASA carriage control 
1011 0000 - Reserved for future use 
licc 0000 - Control record as follows: 
1100 0000 - Job header 
1110 0000 - Data set header 
1101 0000 - Job trailer 
1111 0000 - Data set trailer (not used) 
1000 ss00 - Spanned record control as follows: 
1000 0000 - Normal record (not spanned) 
1000 1000 - First segment of spanned record 
1000 0100 - Middle segment of spanned record 
1000 1100 - Last segment of spanned record 


1000 0000 (x'80') 
1000 0000 (x'80') 


STRING CONTROL BYTE (SCB) 


Binary 
0000 0000 


100b bbbb 
101d dddd 


11cc cccc 


Meaning 


End-of-record 
At first SCB, this also indicates end-of-file 


"bbbbb" blanks are to be inserted 


The single character following this SCB is to be 
duplicated "ddddd" times 


The "cccccc" characters following this SCB are to be 
inserted 
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Appendix B: RSCS Preioader Utiiity Under CMS 


The preloader (part of RSCS Networking) is a utility program that runs 
under CMS. It collects text files and reformats them into a single text 
file that can be dynamically loaded by the RSCS loader. It resolves 
external references and performs preliminary relocation of address 
constants. Its function is similar to that of a linkage editor, but its 
output is in standard text file format and does not include multiple 
CSECTs. 


Line drivers and other programs to be loaded as RSCS tasks may be 
developed as multiple separate assembly modules which externally 
reference one another; the assembled text files may be merged into a 
single RSCS loadable text file by the preloader under CMS. The 
preloader is invoked as an ordinary CMS utility routine: 


PRELOAD loadlist [control ] 


"loadlist' specifies the filename of an EXEC file which must reside on 
the caller's A-disk. Each record of this file contains the filenane, 
and optional filetype, of a text (object) file to be used as preloader 
input. ‘'control' specifies the filename of a CNTRL file which must also 
reside on the caller's A-disk if it is specified. The format and 
interpretation of this file are the same as for the VM/370 VMFLOAD 
utility. If a load list entry includes a filetype, that filetype is 
used to identify the input file, Otherwise, if a control file is 
specified, input file identifiers are constructed using the filename 
from the load list entry and a filetype of the form ‘TXT....' The 
highest control level identifier for which a file can be located on the 
caller's accessed disks is used, If no filetype is included in a load 
list entry and no control file is specified, a default filetype of TEXT 
is used. Input files are located by a scan of all the caller's disks in 
their access order, 


Note: PRELOAD is not to be used to generate the RSCS nucleus. 


The preloader output consists of two files, one with a filetype of TEXT, 
the other of filetype MAP, both with the same filename as that specified 
for the input load list. If either of these files already exists on the 
caller's A-disk, the old file is replaced by the new output file. 


The output TEXT file is the merged and linked copy of the input files. 
The first CSECT or private code section in the input becomes the 
composite (single) output section; its length is the sum of all input 
section lengths (rounded up to doubleword multiples between sections for 
proper section alignment). For the output ESD, subsequent CSECTs are 
made into entries (RLDs), and subsequent private code sections are 
disregarded. External references are included in the output ESD only if 
they remain unresolved. 


Input TXT records of non-zero length are relocated and written to the 
output file. The output RLD is a translated and relocated collection of 
all input RLD records. The output END card does not specify any entry 
point, section length, or other code. No sorting is done by the 
preloader. In general, each output ESD, TXT, and RLD entry appears in 
the same order as the input entry from which it was translated. 


ADCON and VCON fields are relocated within their TXT records. ORG 
statements that cause relocatable constant fields to overlay or to be 
overlaid may cause results that differ from results obtained with a 
loader that completes TXT data loading prior to relocating ADCONs and 
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VCONS. 


The output MAP file is a printable record of the preloader processing, 
similar to a load map. The first line of the map specifies the output 
text file name, its residence volume label and virtual device address, 
and the date and time of file creation. The next section of the map is 
a listing of the control file used, if one was specified. The remainder 
of the map consists of a sequence of input file sections, one for each 
input file in processing order, 


The first line of a map input section specifies the input file's 
filename, filetype, filemode, residence volume label and virtual device 
address, and the file creation date and time. (If the input file was 
located on a disk accessed as a read-only A-disk extension, the file- 
mode, volume label, and virtual device address of the A-disk are 
listed.) If the input file data contains invalid records, the preloader 
writes them in the map sequentially following the input file identifica- 
tion line. The VM/370 VMFASM utility enters such “invalid" records in 
text files to specify the updates and macro libraries used in assembly. 
Following these records, the input file's ESD is listed, including 
control sections and entries with their relocated addresses, duplicate 
external symbols, and unresolved external references, if any. The first 
control section in the input specifies the output control section name; 
the output section length is included on this ESD map entry. 


The preloader does not actually load its input modules into storage 
before generating its output section, but rather interprets, translates, 
and relocates its input text files on a two-pass record by record basis. 
This approach requires that for each TXT record of a particular input 
control section, each RLD entry (one for each ADCON and VCON) which lies 
within that control section must be scanned to determine if it lies 
within the TXT record data. As a result, the preloader processing time 
has a component proportional to both the total number of TXT records and 
the total number of RLD entries for each input control section. Roughly 
stated, this means that when a particular input control section grows 
sufficiently large, the time required to process it becomes proportional 
not to the input control section size, but to the square of that size. 
This effect is significant when a large text file previously generated 
by the preloader is used as preloader input. In this case, much nore 
CPU time may be required to reprocess the preloader output than was 
required to generate it in the first place, because several smaller 
control sections have been merged into a single large control section. 
This kind of program behavior can be expected, and does not indicate a 
malfunction. 


INTERNALS 


The preloader begins by reserving a large block of virtual free storage 
using DMSFREE. This block is used to build a list of control filetypes; 
a table of input file names, the Input File Table (IFT); a composite 
External Symbol Table (EST); chains of elements reflecting RLD entries; 
and a chain of elements reflecting relocatable constant fields which 
span a boundary between TXT records. MAINTOP internally allocates 
storage from the top of the storage block for table entries. MAINBOT 
internally allocates storage from the bottom of the block for chain 
elements. 


INICNTRL reads and interprets the specified control file, and stacks a 
list of default filetypes at the bottom of storage for use in locating 
input files. IFTBUILD builds the IFT by reading the specified input 
load list file, and where no filetype is specified, attempting to locate 
the appropriate input file using filetypes from the control list in 
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repeated calls to the CMS STATE function. When the IFT is completely 
built, the control list storage is released for reuse. The IFT is used 
by INGET, the input read routine, to define the input sequence. A call 
to INGET returns the next sequential record from the input and the 
address of the active IFT entry, automatically switching files on 
end-of-file. 


ESTBUILD calls INGET to read input records, passing control to DOESD 
when an ESD record is read, and to DORLD when an RLD record is read. 
Both DOESD and DORLD return control to ESTBUILD upon completion of 
record processing. When ESTBUILD encounters an END card, the remaining 
file input is flushed, and processing continues with the next file. All 
other input records are ignored. When the end of the last input file is 
reached, ESTBUILD passes control to GENERATE, 


DOESD adds an entry to the EST for each ESD record entry encountered. 
When DOFSD generates a new EST entry, a complete scan of the existing 
table is made for matching name entries. When matches are found, 
external references are resolved, synonyms are chaired (for PRs and 
CMs), or duplicate name definitions are flagged as error conditions, 
depending on the types and statuses of the two entries. A common 
routine, SELECTYP, is used to decode ESD types. SELECTYP accepts an EST 
entry as input, and returns control at a fixed four-byte multiple 
displacement for each EST type group (SD-PC; LD; ER-WX; PR-CM; invalid). 


DORLD builds an RLD chain element for each RLD record entry encountered. 
The SD or PC EST entry for the section in which the referenced 
relocatable constant is positioned is located, and the new RLD element 
is entered at the end of its position ID chain. The EST entry to which 
the RLD element is relative is similarly located, and the new RLD 
element is also entered at the end of its relative ID chain. 


GENERATE scans sequentially through the EST, processing each entry. The 
total output section length is accumulated from SD and PC entry lengths, 
and output addresses for SD, PC, and LD entries are set to their 
cumulative displacements. The output ESD IDs are generated and set for 
unresolved ER and WX entries, (The first SD or PC entry encountered is 
Marked as the ‘prime* section entry, and its output ESD ID is generated 
and set as well.) For each LD entry, the SD or PC entry for the section 
in which the LD is positioned is located, the LD entry is chained to it, 
and the LD's relocated address is generated and set using the section's 
position relocation constant. For each uncompiled PR or CM entry, an 
output ESD ID is generated and set, the maximum length (and, for PRs, 
the maximum alignment) is established and set, synonym relative ID RLD 
chains are merged, and each entry on the synonym chain is marked 
"Compiled". The cumulative output section length is saved for use as 
the prime (output) control section length. 


RELOCATE sequentially scans through the EST, and for each resolved entry 
the position ID and relative ID RLD chains are relocated by adjusting 
each position ID element's constant address field, and storing the 
relative relocation constant in each relative ID element. For each 
unresolved EST entry (all uncompiled PRs and CMs, and unresolved ERs and 
WXs), the output ESD ID of the EST entry is stored in each RLD element 
of its relative ID chain, and each such RLD element is flagged as 
unresolved. 


ESDWRITE starts the output text file generation. An interim file with 
the output filename and a filetype of PRELOAD is used for output 
generation. If such a file already exists it is erased, and the new 
output text file is built. The EST is sequentially scanned, and output 
ESD records are built and written using the EST information. The prime 
section entry is completed by setting its length to the cumulative 
output section length and its address to its displacement (zero), and it 
is entered in the output as an SD or PC. Other SDs are transformed to 
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LDs for output, and other PCs are ignored. LDs are simply entered as 
LDs in the output. Unresolved ERs and WXs and uncompiled PRs and CMs 
are included in the output, and other EST entries are ignored. When 
output generation is complete, if a file already exists with the output 
filename and a filetype of TEXT, it is erased, and the output PRELOAD 
file is renamed to a filetype of TEXT. 


TXTWRITE rereads the entire input sequence from the beginning. When the 
first record of an input file is read (at TXTGET), MAPFILE is called to 
generate and write a map file line describing the input file. When a 
record which does not begin with X'02' is encountered, the record is 
written unmodified to the map file, and is otherwise ignored. When a 
TXT record with non-zero data count is read prior to the first END 
record for a particular file, it is translated, relocated, and written 
to the output as described below. All other input records (e.g., ESD, 
RLD, SLC) are ignored. When an input end-of-file is read, TXTWRITE 
calls MAPEOF, which formats the file's EST entry and writes it to the 
map file. If MAPEOF encounters duplicate external symbols or unresolved 
external references, they are included in the ESD map with the 
appropriate descriptive note, and a preloader status flag is set 
reflecting the presence of a duplicate or wnresolved external symbol. 


For each valid TXT record, the EST entry for the section in which the 
TXT data is positioned is located. The TXT record's position address is 
relocated using its section's position relocation constant, and its 
position ID is set to the prime section's output ESD ID. The section's 
position ID RLD element chain is then scanned for elements specifying 
relocatable constants within the TXT record's data. Each constant field 
entirely within the TXT record's data is relocated with the RLD 
element's relocation constant, provided that the RLD element is not 
marked "unresolved". 


If a relocatable constant field lies only partially within the TXT 
record's data, the output TXT record is adjusted to exclude the overlap 
field, and a call is made to TXTFIX. This routine records the partial 
field data in an ‘overlap element' on a chain in storage, along with the 
address of its associated RLD element. When a previously chained 
overlap element specifying the same RLD element is encountered, the new 
overlap data is merged with the old, and the overlap element is marked 
for output. When the end of the RLD element chain is reached, a test is 
made to see if an overlap element is ready for output. If so, a new TXT 
record is generated containing only the relocated constant field which 
Spanned TXT records, and is written to the output file. The relocated 
(and, perhaps adjusted) TXT record is then written to the output file. 


RLDWRITE sequentially scans the entire EST for SD and PC sections. For 
each such entry, the position ID RLD chain is scanned, and each RLD 
entry on the chain is used to generate an output RLD record entry. Each 
RLD position ID is set to the prime section's output ESD ID. For 
resolved RLD entries, the relative ID is set to the same and the flag is 
set to address type, and for unresolved entries the output ESD ID 
contained in the RLD chain element is used as the relative ID. For CXD 
entries, the relative ID is set to zero. The RLD address field has been 
relocated by RELOCATE and is used as is. 


ENDWRITE writes a simple END record to output. FINIS performs final 
output file processing (already described), releases the main storage 
block using DMSFRET, issues a diagnostic message if duplicate or 
unresolved external symbols were encountered, and returns control to 
CMS. 
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If you would like a reply, please print: 


Your Name 
Company Name ___ «Department 
Street Address 
City 
State Lipp Code 
——_—_— o_O IBM Branch Office serving you 
——<—<_ =: = 


international Business Machines Corporation 
Data Processing Division 
1133 Westchester Avenue, White Plains, N. Y. 10604 


IBM World Trade Americas/Far East Corporation 
Town of Mount Pleasant, Route 9, North Tarrytown, N. Y., U.S. A. 10591 


IBM World Trade Europe/Middle East/Africa Corporation 
360 Hamilton Avenue, White Plains, N. Y., U. S. A. 10601 


First Class 
Permit 10 


Endicott 
New York 
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